2024-05-29--t01-39-05pm--guest77131--nancy-wang
===

Emily: [00:00:00] Welcome to the LaunchPod, a product management podcast from LogRocket. Today, our guest is Nancy Wang, Senior Vice President of Product Operations at Hilton Grand Vacations, a market leader in the vacation owner industry Where she has been for over a year now.

Before that, Nancy spent the last decade of her career working at AlertLogic, 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 the vice president of technical product management.

In her tenure, Nancy led the AlertLogic MDR product scale from 0 to 8 million MRR within two years. On today's episode, LogRocket's VP of Marketing, Jeff Wharton, talks to Nancy about how she leveraged her engineering background to excel in product roles,

her strategic approach to building and leading a comprehensive product operations team at HDV and the importance of planning, transformation, [00:01:00] open mindedness and acquisitions and continual improvement. So here it is our conversation with Nancy Wang.

Jeff: All right, Nancy. So excited to have you on today. I've been waiting for this one. I'm looking forward to this. . So you started in engineering, you moved into product over time.

Can you talk about that journey maybe a little bit and how you came to be in product in that background

Nancy: I often talk to, either to my team or when I do an intro, I talk my about my career journey. It's pretty interesting. I definitely started in the engineering field. First, obviously got my graduate degree in computer science. So very different compared to what I'm doing now. But as I was entering the workforce, I started in wind energy company.

I was in their R. N. D. And I was basically the only person who is not from aerodynamic background, everybody else working in that R and D center. They were all either from Bowen or like some, wind energy companies. Throughout my career, if I look back, I [00:02:00] think the key thing to think through is almost every job that I had, I ended up doing something different.

So as I was working in that wind energy R and D facility, They had a need. When I was hired on, I was doing the basically as a performance simulation engineer. So I was, helping them to run their large turbine simulation model on a HPC cluster. And then we had a need of needing a HPC lab for the R& D center.

And then we were, I remember we were in the downtown building. In Houston, and there's no, The AC is not set up that way. It was a lot of interesting challenges and things to learn. Basically find out what does it need? What do you need in order to have , pretty much like a little data center set up.

So throughout the experience, I learned a lot about, the HPC computer setup, the networking gear, the storage gear, as well as like work through a lot of [00:03:00] hurdles within the building. So eventually had a very nice looking like glass door kind of HPC lab in a downtown building. So that was a fun experience.

And then. That continued on through my career journey that I went to banking, worked for JP Morgan for a couple of years. I really learned a lot about various different systems. So I was in their core kind of Unix team there. And then , where I started pivoting to product is really my previous place.

So I, I worked in a cyber security company called alert logic for about 11 years where I started. There was also on the infrastructure engineering side was really helping them to look at what are some better ways to make sure are the highly scalable processing platform can run more efficiently.

Throughout that process where I went through a hyper gross period of the company where we went from like less than 2000 companies slash customers worldwide to about 4, 000 in a matter of [00:04:00] a year. So we had the need of growing the data center again, from two to seven within that kind of year and some horizon.

So again, a lot of involvement in the. Choosing the best kind of platform system like servers as well as the storage so that because it's our bread and butter, we need to be able to process and store the customer's data in a very cost effective matter. So did that and let the growth for the data center side, and then.

Around 78 years ago, as we saw the overall market and industry is actually pivoting quite heavily to the cloud. That's when the best are booming and Azure and so on and so forth. So we made a strategic decision to uh, basically built a new product in the cloud, cloud native. So that we can better support the cloud customers.

So a lot of heavy involvement again in the initial architecture choice of the infrastructure [00:05:00] set up. Cause it's very different. Although the need, the requirement is about the same, but when we moved to the cloud, everything is very different. So that was a point when I was almost like, Throughout again, throughout all of these, it's always someone ask, Hey, you've done well in this particular effort in the past.

Can you help us on this other side? So essentially we, we call it uh, you know, the replatform and feature parody effort for the new cloud native product. So we build our product, launched it. And then, I was Essentially leading the product effort to make sure that we are looking at the products that we had, which was, accumulated really over the last decade, two decades all the feature functionality and how to move the customers in a very effective way to the new cloud native product.

that was my journey. That's where I ended in the product team. And then I was leading the product team for AlertLogic for, About five years before I moved on to H E B.

Jeff: makes sense. I [00:06:00] mean, Wind turbines finance, timeshare and, and, and property and wonderful, beautiful places. It makes complete sense, right?

Well, I mean, I guess. 

Nancy: different industries.

Jeff: You think about it, right? There's wind in, in beautiful tropical places with timeshares , you need money to go there.

I think it's a good story. But no, I mean, it is, like you said, it's the common theme throughout that you took on new challenges. You focused on making things better and it wasn't just engineering is how do you make the overall thing you were working on perform better as a system which is such a common background I think we see in product people is they may come from disparate, you know, really, really when you get in the nitty gritty disparate focuses, but the big picture is always they looked at the whole system and how do you deliver the best end results, not just how do you do the task or something like that.

Nancy: Yeah. Problem solving in different areas, right? 

Jeff: Exactly. How do you, how do you solve the problem?

Now, and so it's something we've definitely noticed. I feel like looking at, multiple different Probably leaders I've talked to is sometimes people come from an engineering [00:07:00] background. Sometimes people come from all sorts of disparate other backgrounds. The thing when you and I went to school is you couldn't go to school for product.

So everyone kind of came to it from a different way, looking at people who want to enter products now as a career, maybe people who are looking to advance their career. Would you recommend they get engineering experience? Like, Is that. Necessary to really move forward or do you think it's a big step up or do you think it's a nice to Have like how do you look at that?

Nancy: Yeah, so when I look at my kind of my product journey and my engineering background, I think personally it did help me. The reason I'm thinking through like at least the product groups and companies I worked for and I'm thinking about like thinking through the overall industry, I think it's very hard to find any kind of vertical nowadays that don't have to deal with technology in a certain way.

Jeff: So, 

Nancy: It's almost always that the product that we're working on 

Jeff: not, 

Nancy: not saying all the time, but at least in my experience, I'm very calm in the industry the product that we're working on is some have something to do with technology. Having [00:08:00] the engineering background and understanding kind of how the sausage is made per se, I think it does help in both ways in the way when I talk to the customers about.

Like their needs, I can better explain how the, product was built and how the technology kind of work. And a lot of times the customers do appreciate that. And the, 

Jeff: you know, , 

Nancy: helps them better understand and better ask what their needs to be in a different way.

And then talking to engineering has also helped me to translate what a customer wants and what the terms engineering really understand. But. In terms of do I think it's necessary. I don't think it's necessary. It would be a nice to have. However, I've also seen a lot of success in different folks from different experience coming to product, right?

I've seen, people in product management roles, they might came from sales. So in the, 

Jeff: you know, 

Nancy: sales or customer success in those kind of roles in their previous experience. What they're really good at is the people side of it, the relationships side of it.

They [00:09:00] make the customers really comfortable. It's like half of the battle in terms of product, right? A lot of times when the frustrated customer come to us with either feature enhancement or ask folks who had the sales or customer success type of experience It's easier for them to 

Jeff: kind of 

Nancy: very quickly to put the customers in a, comfortable place in a calm way to share like their frustrations with us, or their wants and needs with us from a product perspective.

And I've also seen, folks from, for example, in user experience their previous role was like a UX designer, and then they moved to product. In those kinds of experience, I think it helps them as a product person to very quickly draft up some. Some mock up design around the product features to very quickly.

Jeff: You know, 

Nancy: Obviously, we can always go to the UX engineer engineering team themselves, but as a product person having that experience, they can very quickly reduce that turnaround time and, being able to almost do a brainstorming session with the customer to show. Okay. Is this really what you want [00:10:00] it?

Because a lot of times 

Jeff: kind of 

Nancy: Yeah. Things lost in translation a little bit. So I do think product is a very unique role and a lot of different experience people get from their previous roles would end up being helpful for what they're doing in product. It's, it's, it could vary.

Jeff: Yeah, it's funny. You mentioned that technology now touches seemingly every vertical in every area I know personally if you look at our customer list It's all the tech companies you expect but also, things that touch into waste removal. Restaurants like all the of companies you would think of as Brick and mortar and concrete as possible.

And they have huge tech stacks and are, really tech enabled. So it totally makes sense that being able to speak that language and build the stuff that enables, 

Nancy: I mean, 

Jeff: even, even HGV over there, you guys, I know your team covers, not just one kind of stakeholders, their customer set.

But, when we talked earlier, you described a really complex built out product team that has multiple stakeholders, customer sets Maybe that's a great place to go, actually. Your team, when we talked about it, was [00:11:00] super interesting. And, I think you guys use the term product operations, which is really different from what I've seen historically product operations described as, right?

yeah, that, that part I learned talking to you as well.

Nancy: yeah,

Jeff: exciting too. Yeah,

Nancy: maybe can you, can we dive into this? Cause I, I love this thing. I think this is something that's really interesting is how is your team set up here? And I have some questions I'd love to do this. Can we explain to people like how your team set up and what that looks like and how it came to be?

Jeff: Sure. So my role, I'm the SVP for product operations for HTV technology team. So we definitely report up under the CTO and it's, the previous team. little over a year ago was not a technology team. It was more referred to as a uh, it organization. So the previous leader is a CIO.

So in terms of the current setup it's interesting as we were talking and you were describing to me, like more in, in most of the cases, folks under the product ops. They normally are, the kind [00:12:00] of the KPI team within the product management. But if I were to describe my team, I think the high level is that my team's responsible for the overall, planning, implementation, execution, and launch of the all of everything related to HEV technology uh, roadmap.

So obviously we're not responsible for corporate applications or support, but everything else from, you know, in terms of doing. A new tech stack, a new software solution, or doing some enhancement to our existing tech stack. That's all kind of run through the planning side, but run through in my, team.

And then obviously we partner with the engineering team really closely. So we don't code, engineering team do the, all the coding and kind of architecture, but everything else kind of product roles sits within my group. And then. When I talk about the setup, right? So I'll go through kind of the setup of the team uh, organization, and then I'll go through the reasoning a little bit.

So the team starts with a product [00:13:00] strategy team. the previous name of the team is a business relationship manager. So this is a team who, like you described. We have many different groups of stakeholders. So there are teams who are responsible for marketing their teams who are responsible for sales for resort operations for like the loan servicing part from the finance part for membership and club part of the organization.

So that team really sits very closely with the business. Teams are leaders to understand essentially what is their needs and what is their business problem? They're trying to solve in their unique kind of workflow, and it's largely also echoes back to our overall tech stack distribution, right?

So when we look at our technology stack as a whole, I think roughly 70 percent of the tech stack is actually technology. Used by internal team members, and then about 30%, even though we have 700, 000 members, only about 30 percent of the overall tech stack is directly customer [00:14:00] facing. Obviously, we have the member website, we have the mobile applications, where the members use on a day in, day out basis they're, you know, managing their membership, they're managing their points, they're booking their upcoming reservations and managing their reservations, and so on and so forth.

But then, Echoing back to that product strategy team, we have teams who needs to decide who are the best customers to target market, right? So that's the marketing organization. So they ha they have a pretty unique stack of the MarTech stack that they need to use. They need to score the, members.

They need to know what campaign that we have targeted for a certain group of members. And then , after the prospect phase, then we move to the sales ram, members or the prospects come to the sales centers. You have the sales executives who use another kind of very different tech stack.

They need to have a pretty slick look and feel display at a desktop view where the Account managers can [00:15:00] or the account executives very quickly show the nice resource and the products that we have to the members so that we can build that what potential vacation ownership, the members, the customers would want to buy and after the prospects is happy and move to the purchasing phase, then we have a whole stack around the.

The contract generation, the building, the quote and running the credit check type of software, which is, doesn't need to be as slick from a look and feel, but it needs to be very effective, right? Need to pull all the Credit systems, the loan systems, and we have that kind of set up.

And then we have the call center and club agents who need to be on the call with the members after they become members. So they, need to manage the , membership detail. They need to see all the kind of, you know, reservation and so on and so forth. So that's like another , tech stack.

And then we have 200 plus resorts worldwide. All of those resorts need to use some sort of system to serve the members. So all of [00:16:00] these tech stack, although they're not directly client facing where the client don't put their fingers on them, but having a very good customer experience and for our team members affects directly to what kind of a customer experience that we have overall.

So The product strategy team really sits with all of these internal teams and business stakeholders understand their unique user experience ask and their unique kind of workflow and business problems we need to solve for. And then we have the product management team which really didn't exist before I joined the team.

We used to just have the business relationship management team and then they would get asked directly from the business teams and they would because they're so heavily. Using the internal tech stack, they'll be asking. All right. I need . This button here. I need this functionality added here. And then there wasn't a process or wasn't a product life cycle back then to really ask the question.

All right. Why are you trying to [00:17:00] do this? What problem are you trying to solve? Because as you know, being in product in a lot of cases, folks are using the functionality. They are interacting day in day out. But that particular feature may or may not be what they really should be using.

So , after the product strategy team, we then built the product management team, really just doing, your traditional kind of technical product management, really understanding now that we have the business problem, how should we for it? And, work with architecture, UX, To, to build the potential solutions and then we vet with the stakeholders.

So that team is responsible for the, higher level releases and features and planning and, tracking of the overall technical roadmap. And then after that team, there is the product owner team who then sits more closely with the engineering team, the, basically the scrum team within the engineering team.

And then they're more looking at how do I. Break these features down to sizable user story. So [00:18:00] the engineering can actually solve for them and ensure the end to end kind of feature and releases are really being built right after that team. There is the what I now call release management team.

Previously, the team is called PMO essentially, but it's, you know, the name change. A lot of these name changes are really part of it. Changing the way how folks used to think and operate. So release management team is tracking the overall, project life cycle scrum masters system within that team, too.

So make sure the right kind of s. D. L. C. And scrum ceremonies are run project are tracked and, budget are tracked and ensure the overall kind of launch. Timeline is time launch timeline as well as activities or plan. And then after that team, there is product implementation team. So product implementation team really consists of folks who are implementation engineers.

What they do is, we have 100 plus sales centers. We have 200 plus [00:19:00] resorts. We do need to roll out some big changes or a new version of software. A lot of times you really need to think through we schedule kind of those rollout and really be able to train those You know, sales executives as well as the resort operations staff.

How should they use the new software? Because, they sit at the desk. They're dealing with the customers right at that moment. You can't afford for them to kind of learning a new software on the spot. So we really need to make sure. The new applications we build is well understood by all the internal team members the documentation team sits within that as well.

The knowledge base goes along with the training and implementation. Lastly, I've also recently added a product marketing function within the organization as well. Really looking across cause we have so many initiatives going on. A lot of times the team is heads down, making sure the execution is done.

But really being able to articulate the value of the technology evolution [00:20:00] both with internal as well as with our external customers is super important. So , it's a kind of a quite a long uh, spill about the team. But that really is the, construct of the product operations team within H E B.

Nancy: Yeah, no, I love the detail you can go into here because, you really understand each piece and why it's there. And I think that's the cool part here is it's thought out, but it's thought out end to end we talked about at the beginning product management is ultimately just solving problems.

But you've looked at it in such a complete way , to go from, the previous iteration at HGV, which is very like plan, build, run, to looking at what's the vision. How do we operationalize it? How would make sure people understand what that looks like as they build through, but even I love the piece about having product marketing at the end, because.

In the end, you launch something and people don't know why it's there or what it's supposed to do. Then, you just launched a piece of shelfware potentially. So I love the follow through all the way to completion. And also the release engineers, I think you, you called them that, make sure everything's going out and how do you roll it out technologically.

[00:21:00] And it's really thought through to the end user. It shows a great, View on that kind of how do you deliver something to the end user and make it drive value? Humorously, I also just love that you have a product operations function What you know, most people would consider a traditional product ops function inside your you know product ops team

Jeff: yeah. Product ops within product ops. Yeah.

Nancy: Exactly, it's like product ops squared there. So I do want to I want to put a poll up and see what people would call your meta org here because it

just Encompasses so much

so we're gonna we'll throw that up for sure.

Jeff: Yeah, it's because it's essentially it's the end to end cycle or the pieces are all needed for product management. But then if you call it product management, then people also have different perception about what product management is. So it's, really like into an operations within product management.

Nancy: I respect the completion of the vision of the team there I think it's i'm sure kind of a testament to how you guys are able to deliver so much have transformed the kind of focus of the team and with that I think that [00:22:00] great jump off to we've alluded to it, but you did start out you mentioned the product team started out in the it Oregon and really was just part of the it team and I think it was a very functional, like you said, build a plan, build, run model.

There wasn't, everything wasn't thought out, you thought out what you need to do, but it sounds like, there was often a lot of kind of scope creeped as features came to be delivered. Can we talk a little bit about, the evolution there and how you came in and were a part of this change over the past bit of time?

Jeff: Yeah, of course. I think it's, it's actually, if we talk about the team setup and how the team was run previously, it's not that different compared to the rest of the folks in the industry, right? , when I talk to people within the industry, everybody pretty much is set up. Very similarly, and why when I'm thinking about why I think a lot in a lot of these cases, the vacation ownership industry, the timeshare industry as a whole kind of grew gradually so a lot of times that I T or technology team. [00:23:00] Is more like a, keep your lights on. Make sure certain feature enhancement is done. A lot of times the tech stack used by the vacation ownership industry as a whole is probably built a little while ago because it works.

It's these functional teams that these business units serve their needs. They just built onto it. So in across the entire industry is pretty much all set up that way. And then. Up until probably a year or two ago, I think it works fine, right? Cause the company as a whole is pretty stable.

As I said, like whenever we have growth it's a gradual growth, so it works, but what kind of triggered the need and what changed the way how we operate is like HEV as a company, we essentially Triple the size in the last four years, so we both grew Organically with our customer acquisition our new member growth as well as we acquired diamond resorts back in 2021 so we [00:24:00] You know, diamond is not as big as a TV, but about the same size, so it's not that much smaller.

So you essentially double the company back in 2021. And then similar it again, like in the vacation ownership industry. Similarly Every company has a kind of a similar setup, even though technology stack is different, but it serves all of these needs like marketing, sales contracting, loan servicing resort operations, member services, and all of the entire stack have to serve these needs.

Not only the company group, the revenue group, the the team member size group, the technology stack also at least double, right? You have all these different pieces to look at. And then January of this year, we acquired a blue green vacation. So not as big as the previous acquisition, but very decent size vacation ownership company as well.

And then our member rate our kind of organic max member rate grow significantly over the years, too. So essentially more, [00:25:00] almost more than tripled the company's revenue and size. So not only technology stack, like now you have, essentially you have one of the vertical, which was very complex.

So many pieces. Now you have three different stack. So the traditional way of the. Plan, build, run model , when we were chatting and you were talking about like the like scope creep and the things that we don't realize happens way more often now because there's so much complexity within the technology stack it's very hard for the business teams and the users of the system to really Understand what are the upstream downstream implication for their pieces to work alongside of with all the other pieces and that also like the technology stack and product as a whole need to really be built with a future facing vision so that we can support them the partnership growth and future growth of the company in a very robust and [00:26:00] holistic way.

So So that really triggered the drive from a plan built run to more, okay, let's think about the holistic vision of the technology stack. What do we need to build? And then when there's a specific needs within each of the business units, we can ask the question and then solve for it in a more effective way.

And maybe we build one solution that will solve for let's say five of the different teams needs. So that was really what's triggered the change within the transformation within the team.

Nancy: Yeah. And that makes sense, right? Because it may seem I know. Or rather when I've talked to teams that have made this journey before, one of the big kind of things that, stakeholders were worried about was the engineering team often came in and push back that it's going to slow their velocity.

They're not going to be able to accomplish maybe the same number of points, or if the product team is doing all this kind of fact finding and understanding beforehand, they're not going to have the velocity of roadmap to work on. In reality, I think what you typically see is. In a less planned out environment.

Yeah, [00:27:00] maybe the ticket velocity is a little faster at the beginning, but I think you alluded this before. What happens is you get too close to delivery and. All of a sudden you find out, Hey, we only have solved these three other problems we're touching. We really need to do all that too. And suddenly you're, five point ticket, maybe balloons to 15 and you're late by two months delivering it.

Jeff: Yeah, or the changes that you wrote out actually have some upstream downstream implication that you completely didn't think through. And then that a lot of cases basically end up in reworking. So yeah, like you said, the take a speed is faster if engineering just go at it solving for the individual problem.

But we're overlooking a lot of times of rework that has to happen.

Nancy: Yeah, exactly. There's rework. There's debt you're building potentially. And so it's holistic view. I have never run into a team yet that has found that a year or two down the road, they've actually accomplished more as a result and delivered more value. Yeah. Love to see it. When you're looking at that, right?

You I mean, you didn't have a small team coming into this change. Luckily, it sounds like I know from talking [00:28:00] before, and again, that's something we've seen a lot of companies. It wasn't just you pushing for this, right? It was the CIO? 

Jeff: Yeah not at CTO. Yeah.

Nancy: Yeah, sorry, CTO and engineering counterpart.

We're all on board with his vision. But even with that, sometimes I guess how did it work for your team? Did you find that? Yeah. It was just a matter of enabling people and giving them, responsibility and room to go. Or did you have to find you had to work with certain people to build them up or change processes?

How'd that change management work? Or how'd you people driven towards this?

Jeff: Yeah, I think it's the combination of all the aspects that you talked about, right? So first, it didn't stop at the CTO level. So even before bringing on the new CTO, because the previous CEO retired and he was here for about 16 years, long time, right? So the team was right in a very early stage.

You know, Plan, built, run model for a very long time, but then the executive leadership team as a whole realized that because of the company's growth because the technology complexity growth tripled, we need to look at the overall problem [00:29:00] space very differently. So they, made the strategic decision to bring on my city on board.

So that's the start of it, right? The CTO came on board back in January. I came on board in March and our new head of engineering also came on board in March. And luckily all three of us came from a very kind of similar background where we saw the success within a product forward organization, product led organization.

So the , highest level. Alignment is there and we got the overall executive leadership support. So that was definitely very crucial from the beginning in terms of transformation for the team. Like you said, Yeah, the team is very much, . We're a big company.

We have a lot of things on an operational level day in day out. We need to keep going. We need to keep driving the feature sets to deliver the value for our Transcribed Internal team members to drive future revenue as well as for our customers, right? Because it's a again, big company, big team.

So when I think back the [00:30:00] transformation, I would like to normally think transformation doesn't stop. I think we're still in the middle of it. We're still constantly looking at ways that we can improve and transforming the team even further. But looking back Roughly a year ago. We started this is we did both. So first we grabbed the key kind of leadership thought leaders within the organization. this is across not only within the product engineering team across all of the team, like corporate applications support. So all of my peers and their key leadership.

We got everybody together and we went through a programmatic product management training. To really kind of honing on the concept of what does product management really mean? Like when we think about and talk through the product management life cycle, it starts from concept to alpha to beta to GA to launch, these concepts, it was crucial to go for everyone to go through the same training course.

And then , We align on the same terminology and thinking process and [00:31:00] at the back of that, after the training, we also did a couple of days of like brainstorming and really plan out the what we call the mind map. What are the things that we actually need to build because we know we're taking on this digital transformation journey of our.

Technology stack, we need to both consolidated as well as build it for the forward needs and really provide the best in class experience for all of our customers, integrate with modern AI technology and machine learning and recommendation and all of that to the members we planned and. all brainstorm around the overall mind map and the blueprint for the technology team.

So that was really critical up front. And then throughout the year, right? It's like the standardizing on the process as well. Like after the first alignment on the concept, I wrote out A standardized product management tool also kind of mapped. It's connects with the development software that we use.

[00:32:00] So it's like product and engineering software is completing in sync and we have a very cohesive like view of what is product priority and what is the engineering teams working on. And then as part of that, as part of rolling out the standardized tooling, we also standardize kind of the rituals and meetings, the scrum of scrums, and the stakeholder sign off, like these product ritual meetings are standardized across the board as well.

So it's throughout, that's how we transformed the organization. And then along the way, like I mentioned previously, we didn't have any product management team. We had one. I grabbed one that was really working in a product management capacity you know, got her on boarded on the team, but , some of the other folks , we had to hire, especially like folks like user experience, you do need to kind of folks who had that previous experience and that bring into the organization.

So combining having new folks. building relationships as well as like transforming the existing team and then [00:33:00] really collaborating as a holistic team. That was what kind of contributed to the success of the organization transformation.

Nancy: I think people often overlook the rituals. That's an easy piece to think, Oh, it's not important, but it's that piece of kind of regularity and coming together and making sure everyone understands the vision. And I have found, I think, early in my career as a leader, I eschewed and stayed away from and thought they were a little hokey or a little kind of, no one wants to hear me repeat the same stuff again and again, but you come to realize.

Just when you're getting tired of saying something is probably when people are really starting to hear it. And the regularity of the repetition helps people stay on. But the other thing is artifacts, right? And, we've had a bunch of great people on this podcast who have talked about, whether it's Carla Fisk, who's over at Tebra, and she talks about literally a product placemat that she got from a colleague of hers over at Target or Sarah Owen from OneInk has, they've developed this thing they call a magic mountain, which is it's all simple.

Like the best of these are so simple. It's a picture of a [00:34:00] mountain with the top North Star gold and it cascades down and breaks up into sub goals and how they all drive up. But the thing they all have in common is it's a simple way to communicate. You have one or two big complex goals. How does everyone's individual piece ladder up?

And I think that's an easy thing to lose when you move from the , plan, build, run. You tell someone do this thing. They live in their little vertical slice and they always know what's going on up and down, but this is more complex, but the end result can be a lot better. So do you folks over at HGV have any artifacts like that or anything like that?

Jeff: Yeah, we do. It's I think it's both in an artifact as well as also just a constant kind of ritual. And like you said, reiterate from the strategy down to the pieces. Everybody is working on. So We have a tour, artifact that we call my map s O. That's the mind map that we build from a year ago.

And then we actually use this in my previous company as well. So as we were doing the, re platforming for the product, we [00:35:00] build the mind map. And it's again like A couple of days, probably a week or two brainstorming sessions and with folks who really understood the complexity and the features for the technology stack that we had or product stack that we had built out throughout the two decades and then we know what we need to build in the new. platform, new product in order to, really fulfill the vision. So think of it , as like a color coded tree almost and then as we were building the feature set and as we were launching the releases, it was very fulfilling as I was leaving, looking back. Um, you know, Almost I would say 90 percent of the bubbles of the mind maps are all lit up.

So that's essentially what we're following here, too, because we know the big pieces that we need to build. But then each of the bubbles actually takes time , to build and develop and, mature and make well. So when the team when we talk to the team, we often refer back to the mind map and say, Hey, this is what we're building holistically and how this is contributing to the [00:36:00] overall vision.

Nancy: Nice. Yeah, that exactly. Everyone has their own. It's funny. Everyone has the unique thing, but it's always there. I, this is something I really want to put together and start to collect as a whole, maybe swipe file or swipe folder of all these kinds of different artifacts and how everyone makes it their own.

I think people could do so much with that. 

Jeff: we also one thing to add is we also like you said, it's like up until when you everybody is tired and everybody can actually repeat it almost word for what the leaders are saying. That's getting the message across, right? Just having the tool is not enough. We have our CTO kind of reiterate the.

Strategy often with our executive leadership team. We have multiple layers of the meetings where you know, we have our CTO myself and the SLT leadership also talked to the teams very often about the vision and what we're working on. And don't forget this is the vision. We were getting the pieces.

How does that fit in? So it's the constant kind of communication along with the tooling is [00:37:00] very important to get the point across.

Nancy: Yeah. I definitely, I learned that the hard way years ago that you can't tool your way out of a problem. It can help you, but the tool itself is not going to do it.

Jeff: That's right. 

Yeah, 

Nancy: and I gotta be honest, is there anything better than looking at a checklist or a mind map and just seeing all those bubbles colored in or

checked and and just knowing 

Jeff: Yeah, It's fulfilling. 

Nancy: fantastic. I want to make sure, we're running short on time. I want to make sure you get back to, your actual job of delivering great product for the several, thousand different stakeholders you have over there. Quick hit you know, you folks are HEV have, you've acquired a couple of companies.

yourself been on the other side and been a company was acquired, what in 60 seconds or less, what kind of tips can you give to someone facing either side of that?

Jeff: it's actually what I look across and looking at the industry news to I've, I've, I see that acquisition happens very often. Now, it's almost like a industry strategy to consolidate and optimize and then, make sure we're all stronger on the other end.

So being on. [00:38:00] Previous company, , I worked on the new product. Eventually that led to a successful acquisition. So my company, about a year before I left, was by a bigger company. And now, we acquired two pretty decent sized companies in the past couple years.

So looking at both and being on both sides, because it's a lot of times it's about to look at how this the combined team can better perform on the other end after the consolidation and then. During the integration process, it's kind of common and hard problem to solve for it. Like we need to figure out how the technology stack and how the team can integrate together.

So the one advice I would give to people is keep an open mind. So it's oftentimes because , we are very attached and we're very attached and very proud of the product and tooling that we use and the product we build. But. Being on the acquired side, have an open mind and [00:39:00] suggest solutions to the acquiring company to say, all right, when we look at the holistic problem, here's what I think going forward is the best for the combined organization.

And then the same thing for the acquiring company, when we acquired another company, it's like. Both from a people perspective as well as from a tooling and software perspective, keep an open mind. We will actually have a very holistic and working well together team and technology stack at the end of it.

If we all keep a very open mind and don't be scared, right? Because a lot of times, especially on the part of being acquired side, you might say, all right, these people are acquiring us. They might not like the technology stack we have. They might not trust what we say, but. You never know just, again, keep an open mind, suggest what you think is best for the goal forward, and then, I think the rest of the tiles will fall in their own place.

Nancy: Makes sense. Nancy, it's been fantastic having you on. I really appreciate you taking the time to come sit with us today. If [00:40:00] people want to follow up and ask questions or get in touch with you, is there LinkedIn or something? Is there a good way to get in touch with you?

Jeff: Yeah, they can search me up on LinkedIn, Nancy Wong at HEV, and I will be following up on your blog post as well if there is one. So I will look at the comments. I'll answer the comments. I would also want to find out what people might call my team, right? It's if it's product off square or some other name for what they might refer to as my team.

Nancy: we'll definitely get that poll up. I'm excited for it. So awesome. Thank you so much and it's been a great time 

Jeff: Yeah, thank you for having 

me.