Scaling product centric organizations — a.k.a. that moment you are not in a “garage” anymore
I joined Collective Health as Senior Product Manager at the beginning of Thanksgiving week in 2014. At that time the company was about 40 people strong, 4 of whom were Product Managers, including the Head of Product, myself and another fellow that joined at the same time as I did. Our home base was a run-down office space in downtown San Mateo with great karma (where Collective Health’s CEO’s previous company, AdMob, grew their business), but with metal tubes falling from the ceiling and a dubious layout.
Despite these quirks, that space was certainly beloved. We were forced to move on because of our rapid growth. By November 2015 we had about 130 people and no place for them despite the fact that many gave away their permanent desks.
The move was quite well timed, sandwiched between our successful fundraising round, concluded in October, the launch of the second iteration of our user facing product in mid December, the Member Portal, and our brand new iOS app. For context, users, or “members” as we like to call them at Collective Health, are employees who have selected Collective Health for their healthcare benefits through their employer (our customers).
As the product manager in charge of all Collective Health member experiences, I knew that our growth meant much more than just growing our audience to over 30k users and having to satisfy more demanding clients. It was about moving from a setup where one PM (myself) would fully own the user experience, to an organization where multiple PMs would collaborate as owners and experts of specific components. While this would create some coordination overhead, it was needed to allow a deeper understanding and development of each product component in a way that would have never been possible with one person alone.
While highly collaborative “PMing” is certainly not a new thing at most large tech companies (here a great article about the Group Product Manager role), executing such transitions without letting things fall through the cracks is always a challenge, dependent unique dynamics of the organization.
In my experience, structure, process, and attitudes are the 3 fundamental themes to get right in these circumstances.
Structure means clear ownership and accountability
Everybody must know who is responsible for each product component (or process if we are not talking about PMs). This is the key not only to make sure that that person is empowered to make decisions, but also to make sure that any relevant information is funneled towards him/her. Only in this way the owner can successfully identify requirements, evaluate trade offs, and ultimately propose and carry on improvements to the product.
It’s certainly challenging to define clear boundaries on ownership, especially for organizations where most people are used to wearing multiple hats. Such situations are really common in small startups. The main challenge is that untangling and separating responsibilities can give the people previously in charge the uneasy sensation kids have when somebody steal their toys.
I certainly felt that way in the first weeks of our transition, but soon a peaceful sense of liberation emerged. I realized how lucky I was that multiple people could dedicate much more time and energy to further develop components of the Member Portal that I never had the bandwidth to address with depth. I also realized that, actually, I have been “giving away my legos” throughout the whole year (“Giving away your legos” is one of the best articles I have read on the topic). When I joined in late 2014, I set up and ran our QA process and activities, and then passed them to our newly formed test engineering team in mid 2015. Until 2016, I was both prioritizing the product backlog and running my scrum. Now I am extremely happy to fully focus on feature definition and prioritization after a real scrum master helped us with standing up a strictly agile development process.
The reality is that most of the time a clear way to define responsibilities doesn’t exist. It is not only about how the product components fit together logically, it is also about how the rest of the organization is structured and what specific skills/interests are available in your team. It is a bit like a Tetris game. You certainly need specific shapes to complete your organization, but also you need to fit the shapes you have into the existing organization. There is no point of trying to fit the shapes you don’t have.
For us at Collective Health, it means having a matrix organization with PMs owning user-specific touch points such as the Member Portal and Outbound Communication Experience (I still own that) and PMs owning components available across touch points, such as our provider search experience. Today the owners of those touch points control engineering and design resource allocation within each quarter, while the resources get allocated across pools on a quarterly basis (more about the product prioritization process in the next section).
Relative size also matters. One of the most used measures for this are the engineer/PM and designer/PM ratios. Each organization has a different target ratio depending on their specific business model and goals. While the big guys in tech (e.g. Google, Facebook) historically target 6 to 10 engineers per PM, at Collective Health we believe that 3 to 1 is the right ratio for us. The business and legal requirements of our healthcare product add complexity and supersede the engineering complexity of simply building the product.
Process is about clear decision making and communication flows.
It’s about clarifying who makes decisions and how decisions are made. It also must be clear how the information to support decisions is collected and how anybody in the organization can get the required information to the product owner. It is a fact that good decision making is is only possible with appropriate and complete information.
Communication is the key to successfully executing the decisions being made because it ensures buy-in from the organization, which in turn, needs to align to support the selected approach. Organizational size increases the needs for clearly defined communication flows. While you can still (possibly) share information and make decisions by interacting with 10–20 colleagues on a daily basis, when you regularly have meetings with over 20 different people it’s clear that you are really not using anybody’s time effectively.
There are several types of processes that, when run at the same time on a recurring basis, allow organizations to achieve both decisiveness and effectiveness (depending on the organization size: not all processes are needed at any given time):
- Strategic planning: with a 6 to 12 months cadence, it allows you to identify the key goals and metrics to strive for. One of the most interesting frameworks I have seen for this is the Big Hairy Goal framework.
- Strategic initiatives prioritization: it’s the evaluation of resource allocation on a shorter cycle than the strategic planning (usually between 1 and 6 months) to rapidly respond to environmental changes. Allows organizations to move away from the “prioritization by screaming louder” and to establish a “rational, consensus driven process” that allows to evaluate potential initiatives with the same criteria. One example of this that inspired us is “the Pandora approach”.
- Individual goal setting and evaluation process: with a cadence in between that of the strategic planning and of the strategic initiatives prioritization, it allows each member of the team to align their own performance goals to the company’s goal. The most classic and praised approach is the Objective-Key-Results adopted by Google and others. For a successful implementation of such framework it’s essential to separate evaluation criteria from OKRs to avoid incentivizing people to game the system.
- Ongoing stakeholders’ updates and feedback: between prioritization cycles (every 2 to 6 weeks) it’s important to monitor the execution of the prioritized initiatives to ensure success and to incorporate feedback from the key stakeholders as early as possible. In the product world some people call this “Product Council”.
- Continuous operational improvements / feedback: it’s important to continuously (daily and weekly) capture feedback from day-to-day operations not only to rapidly address problems, but also to build up the knowledge that will be used to prioritize larger initiatives in the future. This process should also be used to ensure that all departments are aware of the existing roadmap and solicit feedback on it.
- Design and build sprint cycle: all the processes above have really the only one goal of making sure that day to day, and week to week, the talented designers and engineers focus their bright minds on the right problems.
Setting up these processes correctly is like having a healthy personal routine that allows you to spend most of the time “doing things” vs constantly evaluating “how to do things” or “how to decide what things to do”. Moreover, this isn’t only about collecting information from across the organization for prioritization purposes, it is also about having all departments feeling listened to. It is about making sure they understand how to interact with each other and with the product team, but how the prioritization is executed and feeling confident about it.
The decision-making dynamics in each of the processes described above is very different. Strategic planning level decisions (1) are mostly driven at the director level after a prolonged period of preparations in which each department head collaborates/discusses with his/her team about the ideal target for the group. Product prioritization (2) involves the minimum number of key stakeholders who should commit to the initiatives for the upcoming quarter after assessing all potential initiatives that have been carefully crafted and analyzed. Continuous operational feedback (5) is how PMs get feedback to prioritize features that can be built in a few days/weeks, by setting the right priorities for the design and engineering sprint (6).
All of the above is very beautiful, but is it feasible? The right tooling is certainly vital to make sure these processes run smoothly. As there isn’t a silver bullet to apply to this, each organization needs to grab the bull by the horns and try different approaches and implementation techniques until they find what is most suited for them.
At Collective Health we found that continuous operational improvements (5) and design/engineering sprint (6) cycle were immensely facilitated by weekly recurring meetings, retrospectives and Jira dashboards. The rest of the processes require a bit more hands-on preparation: shared frameworks, deep research to prepare the right support material to discuss ideas within a certain framework and just more time. Additionally we are experimenting with multiple communications channels such as Slack and Product Homepages/Blogs (Confluence by Altassian) to provide a central hub for communications and updates for the interested parties.
Attitude. For some this is organizational culture, for me it’s about empowering everybody to be the best person they can be, and ultimately be happy.
As humans, our life is made up of the by little things. I am talking about that warm feeling and smile that you can’t stop from forming when you see a good old friend after many years. I am talking about that moment when you find the energy to achieve what you wanted while doing your favorite sport. Those are the moments that you need to be able to re-create in your organization in order to empower your people to blow out of the water completely any big hairy audacious goal that has been set by the leadership.
It is about taking responsibility for making your coworkers happy. For involving them as much as possible in decision making, walking that fine line between efficiency and building consensus. For listening to them. For encouraging them to take responsibility and not pointing fingers if things go wrong. For allowing them to focus on what matters. For maintaining a workplace based on trust and respect. For not succumbing to the loudest voice in the room. For intervening when somebody gets out of line. For identifying what battles are worth fighting. For ensuring they have time for their personal life, vacations, and decompressing. For being mindful of ours and their feelings and needs.
This has been part of my experience at Collective Health so far. We are certainly on a crazy ride over here and I am excited and scared to see what is around the next turn and what I will learn there. Sure enough, the prompt of writing an article on my Product Management learnings that came from the Product Mentor Program was well-timed. Otherwise I would have not spent the time to gather my thoughts in such an (un)organized way. Also, it’s thanks to Ian Moulton, the mentor I worked with during these months in the program, that I achieved the level of clarity that allowed me to write this piece.
