Building a New Team and Moving Fast

One of the highlights of my career so far has been working on a greenfield project for guest engagement at my current company, Cloudbeds (a cloud-based hotel management platform). I learned through this project how to build a team and product from the ground up and wanted share my journey and major takeaways. I was completely brand new to the hospitality industry and had just learned what a PMS was. I was asked to build a brand new team, integrate a newly acquired platform into the product, and determine what product features should be prioritized and built on top of the acquired product to maximize value for the customer. The final goal was to pilot and then eventually prepare for a general release. And in addition to all of this we had a pretty tight deadline—delivering a pilot for a brand new platform in 2 months to 25 customers. 

Now as a product manager, that is some pretty stressful stuff. Immediately, my brain began doing the math on what exactly 2 months meant. 2 months is 8 weeks and 8 weeks means 4 sprints (if you’re doing 2 weeks per sprint). The clock started once engineering had fully onboarded and the product acquisition had been completed after which we needed to take the existing platform and re build the infrastructure so that we had a version of the platform exclusively for Cloudbeds. Afterwards, we needed to figure out what were the low hanging fruit features we could build well and fast to add additional product value for Cloudbeds customers in order to differentiate our version of the platform from that of the original version that is available for non Cloudbeds customers. 

In order to set our team up for success given all of these factors, I decided to hyper focus on what absolutely must get done. I began by working with my engineering manager counterpart to determine our agile process that we’d follow for the team (i.e. 2 week sprints, backlog refinement, retros, etc.) and general team procedure which I documented in a Team Playbook (a concept I picked up from my time at Microsoft). If our team was going to succeed we needed to have an agile process that everyone was onboard with that worked towards us failing fast. With a Team Playbook and process in place, I began to look to understand more about the newly acquired platform for guest experiences, Whistle, and Cloudbeds as a whole. I scheduled time to speak with other product managers, product marketing managers, customer support agents, user researchers, engineering managers, and sales. During each call I would try to learn more about the company, the different projects in place, and the goals of the organization. I also began to work to familiarize myself with our tech stack and had one on ones with engineers across the company to understand how our product was built and asked our engineers to walk me through the technical documentation and infrastructure/architecture diagrams that described our product. 

Powered with this knowledge, I dived into heads down visionary product work. I started to think about the North Star goals and metrics we wanted to accomplish. Our goals were focused on retention, acquisition, and conversion. I began to also think about what the perfect, life-changing guest experience product would look like for customers and then worked backwards from there to determine where we’d need to start to get to that final vision. I constantly consulted with other product managers more familiar with the hospitality industry and relied on user research to provide further guidance to understand our customers. Another fundamental part of my work was to partner closely with the engineer and former CEO of our newly acquired product to understand what customers cared about most, what their needs were, and what features they suggested we build first as our low hanging fruit. We collaborated heavily on our team and I’d always bring in all our engineers into the conversation to think through what we could develop for our pilot given our vision for the product. I wanted us all to feel like we owned the product together. This helped us develop a roadmap to tackle for our pilot and build a solid culture of inclusion and collaboration on the team.

Aside from the day to day of driving the team, I needed to mobilize our partners across sales, marketing, support, operations, pricing, and finance to prepare for everyone being familiar with our newly acquired product, the features, and successfully communicating all this information to our customers to then execute successfully on sales. Initially, the director level folks were involved in the weekly syncs to move this work forward but I noticed that proper action wasn’t being taken and there was at times miscommunication. Naturally things were getting lost in translation as the directors attempted to trickle down information to their team leads and folks weren’t conveying all of their hesitations or concerns in front of their directors. I asked that the directors no longer be involved in the conversations. Instead, I put together a weekly sync with the individual contributors on the teams across our different partners since these individual contributors are the people that were getting the job done. It was a huge success. We got together each week to discuss all new product information and escalate issues across the teams that needed to be addressed. Each meeting I would send out an agenda in advance so people showed up, take down a list of notes for work that needed to get done, and assign at the end of the call who would be responsible for following up. I worked on creating a big team atmosphere where we all recognized that we were working together towards a common goal by repeating that we were there to build a great guest experience platform for our customers. 

Naturally during this process obstacle after obstacle came up and there were times when we didn’t think we could make our deadline to pilot. However, we always pivoted. If a feature was larger than anticipated, we reduced the scope. If there was a blocker with communicating directly with the customer, we implemented in app messaging. If customer support needed help with answering questions, product would jump in. We all came together successfully as one Cloudbeds team. Additionally, I learned from and made mistakes along the way. I contributed to scope creep, I didn’t push back enough when I felt that something was wrong, and at times didn’t engage with my leadership early enough to escalate issues. I’m very grateful for these failures because I learned how to prioritize more effectively, communicate more clearly and push back effectively, and about when to ask for help to not delay the work.

I am very grateful for all the people that I had the opportunity to work with and all the passion, time, and effort they put in to make our pilot a success. We launchd our pilot in August only 2 weeks later than we had planned for. Looking back, the investment that I put in to build relationships with the people across our company on a personal level, the work I did to learn about the technology and product, and the focus on building a solid team process and culture was part of the formula for success to help us build and move fast. I feel exceptionally lucky to have worked on a project of this scale so early in my career. 

Next
Next

What I Learned About Promotions