Establishing the Goals for an Acquired Organization

Problem

A year ago, I joined the office of a startup bought by my current company not long before. The acquired organization developed an exceptionally disruptive product within a flexible job marketplace ecosystem that had a massive penetration across the UK. My company bought them with the intent to expand their product across the US and globally.

This startup was established in 2015 and being focused on fast growth, it didn’t have much time to develop internal processes and best practices to build products. However, when the time to scale came, the lack of processes and best practices got them stuck. So I joined the office to build the team, scale the product, and consequently also scale the team. By the time I arrived, there was only one PM and designer on the team, and the task of expanding to the US and globally seemed humongous.

Actions taken

For and foremost, I initiated a series of conversations with various stakeholders across the organization to understand better what we were trying to provide to our users. Our users were a rather diverse group of people: clients, prospective employees looking for a job, or internal employees working in Operations or Finance. Through those conversations, I tried to comprehend the value that we could bring to all those different stakeholders. Also, I had to understand our unique selling proposition and the specific problems we were trying to solve for those different stakeholders.

I also spent many hours reading our user research, which, combined with extensive conversations with various stakeholders, allowed me to propose a structure that would make the team grow. I came up with a flywheel structure, and I managed to identify critical narratives within that structure that would enable us to move forward. I also had to define key metrics for each area to measure how well this organization was performing.

For every area, I had a product analyst who helped me drill down into the key metrics I wanted to see for each of those areas. For example, I broke down adoption-related metrics into how many jobs are being posted, how many are accepted, what is the fulfillment rate, what is the contact ratio, etc. Looking at those key metrics gave me a full view of the strengths and weaknesses of the acquired organization. I also did an exercise to identify key value streams and personas, which gave me an idea of how the organization was structured. The first exercise helped me define four future value streams: client experience, worker experience, employer experience, and internal tools. Then I had to define goals for each of those four verticals.

For example, for client experience, we had two main clients with simple, easy-to-use tools. The same would apply to all other verticals. I had to establish goals for every vertical with metrics that would tell me if I was moving toward the goal. Those became global metrics for each of those verticals. Inside these verticals, I had to identify different areas that would help me achieve global metrics for each of the verticals. For example, if worker retention would be improved in the worker experience area, that would indicate if workers were happy or not. For each vertical, I came up with three to four key metrics that were tied to global metrics for that vertical. In the end, I combined everything, bottom-up and top-down, so that the lower metrics became my input metrics tied back to the larger organizational metrics.

I have always been driven by three Ps -- people, processes, and products. I first figured out what needed to be done, how the business operated, and what the main KPIs were. Then I brought into a meeting engineering leaders, a PM and a designer, and within a month, we managed to complete defining the first level OKRs -- which at that time I didn’t refer to as OKRs but key metrics we needed to improve.

Then, I had to understand what were the right people to hire for each metric level. I had to hire someone for Retention and Adoption because those were key metrics, and I prepared a hiring plan accordingly. Within six months, I grew the team from two to ten members -- seven PMs and three designers. The team was structured to address key user problems. For example, one product director would take care of the entire worker experience vertical and have two PMs beneath for each of the individual metrics in prioritized order.

I also aligned the engineering team to ensure their support to their product counterparts. Six months within the process, I called for a meeting of the entire engineering and product team to discuss OKRs. We reprioritized OKRs and built both a one-year vision and a three-year vision with its key metrics. This time I built more detailed metrics because I had a much better understanding of what were the inputs impacting the outputs. But, we didn’t stop there. The team will further grow to 30 people, which would be a 3x increase, and the business would increase 8x in the next year according to the current plan.

Lessons learned

• Build trust with your peers before embarking on such a significant transformation.
• Think about your users when building the team. Keep in mind who they are and what value you provide to them. Your team structure should reflect that.
• Don’t rush to hire people. I was under tremendous pressure to hire fast, but I was resolute to find the best people and take some more time if needed. I didn’t want to compromise the quality over speed. Even if that took two months more, it would be easier to move forward that way than hiring the wrong person.
• Go deep. If you don’t go deep, you won’t be able to add value. Don’t hide behind a product leader title that can allow you to delegate things and remain at the surface. Instead, deep dive into a problem and be a leader that makes a difference.