Product Managers (PMs) often struggle with maintaining operational processes and wish they had more time for what they love most, the core product, and companies also benefit from PMs who can dedicate themselves fully to further evolving the company’s value proposition, securing future revenue streams. On the contrary, a product that can only be operated on inefficient processes will prevent a company from scaling, thus harming the business in the long run. As a consequence, we need to understand what a PM leader in an organization can do to combine product and operations in the most efficient way. This post evaluates different team setups to help you understand their individual benefits and fallbacks, enabling you to decide how to best structure the teams in your organization so that product and operations can both become the best versions of themselves. Let’s make this marriage work!
In this post, we are concerned with products that require some kind of operational process to be in place for the product to provide value to its customers. This is in contrary to stand-alone products that provide value in itself and are not depending on any operational process to deliver this value. An example for a stand-alone product is a calculator app where the app in itself is providing value to the customer. The app has already all it needs for providing value bundled within it, i.e. the user interface and the logic to transform any customer input into adequate output. On the other hand, taking the stock screener app of SuperStockApp, Inc. as an illustrative example, their stock screener app is not able to provide value in itself. While a screener app may also have the screening logic implemented, this logic not only works with customer input, e.g. filter criteria, but also relies on external data, i.e. data from recent financial reports. Obtaining this data and making it available to the screening logic is an operational process and without it the app is unable to provide value to the customer. Even worse, this operational process is repetitive because financial data for all companies to be screened changes over time and hence it must be updated continuously for the product to provide continous value to the customer. For the remainder of this post, we will only focus on products that require operational processes.
Option 1: PM Superhero
Initially, a product may be conceived by a single PM which is the case in early-stage startups or in organizations that are experimenting with new products. The first step is always to build a Minimum Viable Product (MVP) and, if the feedback from customers in response to the MVP is promising, then the MVP becomes an established product in the market that is getting traction. In this case, a single PM is able to do it all: the PM defines the value-proposition of the product and even sets up an operational process to make the MVP or early product work. However, the operational process may not be designed for efficiency right from the start. Especially in an MVP, your goal as a PM is to get to market as fast as possible so you can evaluate your product and hence refine it as quickly as possible. In this early stage, you will not focus on the most efficient operational processes, but instead on making the product somehow work. Using again the stock screener app as an example: in the MVP the financial data could even be provided by manually collecting it from the financial reports and entering it into a database table. At this early stage, there is no point in making an operational process as efficient as possible if it is not clear whether the product will take off at all. The time can be spent more wisely otherwise.
If the MVP is successful and the product is getting traction, the manual process will be very quickly limiting the growth of the product. In our example, customers expect as many stocks as possible to be screened and the manual effort associated with that process is no longer sustainable. As an inevitable consequence, the PM will now have to spend time on defining what a scalable operational process needs to look like and work to put it in practice. This time is no longer available to keep advancing the value proposition, e.g. by adding further screening algorithms to the app. Instead of focusing 100% on advancing the features of the stock screener app to remain competitive in a fast changing market, the PM can now only do that in a fraction of time and must dedicate the remaining time on designing and implementing a scalable operational process, e.g. 50% product work and 50% operational work. Although this will slow down the evolution of the value proposition, it is a necessity because without a scalable operational process in place, additional features, e.g. alternative screening algorithms, will be irrelevant. There is no point in having multiple screening algorithms if the subset of screened stocks is way too small as compared to the competition. The most innovative screening algorithm that you could potentially add will never make an impact because the value proposition is heavily limited by an inefficient operational process. Now it is time to change the team setup so that both tracks, product and operations, can be progressed at the same time.
Option 2: PM/BA Dynamic Duo
Before we explore this team setup further, we need to define the role of the Business Analyst (BA). The BA was chosen here because in larger organizations BAs are typically hired to support operational processes. There is no single definition of this role that is valid across all organizations, but in the context of this post we will use the following distinction between a PM and a BA:
The PM is responsible for delivering and evaluation the features of the product that promise value to the customer. The BA is responsible for the operational processes that enable the features to deliver their promised value to the customer.
In our example of the stock screener app, the BA will need to understand which data the screening algorithms (i.e. the features of the product) require and how this data can be obtained. If the initial operational process is fully manual, the BA provides value by revising this process and coming up with ideas how to turn this very manual process into an automated one. The BA may even change the process if this proves to be more efficient, however, the BA should not modify the value proposition itself, i.e. altering the features that the PM has defined. If the BA sees a need to do that because otherwise a more efficient feature cannot be put into place, PM and BA have to find a mutual compromise.
By adding a BA to the product team to cover for operational processes, the PM is now freed from this task and can allocate the majority of time to evolving the product and its value proposition. This does come at a cost but if the product has proven to gain traction and the product is only limited by not being able to scale, this investment can unlock future growth and, thus, amortize the cost.
Option 3: Three Musketeers
Depending on the complexity of the operational process, tools may become required to increase the efficiency of the process through automation, but also to reduce the number of potential issues with that process. Again, let us take a look into the process optimization project that SuperStockApp, Inc. launched i their efforts to scale up their product and hence their business.
The BA may have identified critical improvements to replace the manual process with an automated one. For one, financial data may be available from third-party data providers or even from public authorities such as the Security and Exchange Commission (SEC) in the United States. The BA may now design a process where the data is fetched periodically and, in addition to merely obtaining the data, the BA may even add a Quality Assurance (QA) process on top of it to make sure that potential problems with the data (e.g., zero values where they are not expected) are automatically detected. In this scenario, the BA is looking for tools that support the improved operational process.
The product of SuperStockApp, Inc. is a very specific one in the market and hence there are now off-the-shelf tools available to support the improved process that the BA has envisioned. This is the point in time where the company needs to build the tools themselves to enabling scaling and future growth. Similary to when the BA was hired, this comes with additional costs but these costs are acceptable if they unlock future growth. Do not forget that by sticking with a manual process the company would also incur additional cost because then it would need to hire people to scale up the manual process. The rationale here is that by implementing the tools to operate an efficient process, the investment will be significantly smaller in the long run. Ideally, the process is decoupled from the volume that the screening algorithm is processing. This leads to an important insight:
If in your organization there is a proportional relationship between an operational process and the number of people required to run and maintain that process, your organization will never be in the position to reach an exponential growth path which is what so many startups and especially their investors are aiming for.
In this specific case, it does make sense to bring in another PM to take care of the internal toolchain that is required to implement the process improvements identified by the BA. Now we are setting up a team with two PMs and one BA that for easier reference shall be called the Three Musketeers from now on. It is important to understand the differences in responsiblities for these two PMs. The PM that is responsible for the customer-facing part of the product is not concerned with whatever tools need to be put in place to be able to run the operational processes. From now, we will call this PM the Proposition PM. The Proposition PM is working on part of the company’s product that has a direct impact on the value proposition and hence the customer. Therefore, such a PM needs to spend a considerable amount of time on customer and market research. The second PM that is brought in to make the internal tools become a reality, only has an indirect impact on the value proposition. If the tools designed to run the process lead to incorrect data, even the best value proposition can be adversely impacted and customers may lose trust in the product, even though the product is exactly what the customers need. Therefore, the role of the second PM is no less important than the role of the first PM, however, their customers are more internally-facing than externally-facing. From now, we will call the scond PM the Systems PM denoting that this PM is not directly impacting the value proposition like the Proposition PM, still the Systems PM is crucial for delivering the best possible processes within the company.
Option 4: PM Tag Team
Having established the responsibility of the Proposition PM and the Systems PM, one could question the role of the BA: is it really necessary to have an additional BA in-between both PMs or could we omit that role and just create a PM tag team that is working closely together? The world is never black and white only, so that is indeed a possibility but there are again benefits and drawbacks that need to be pointed out.
We introduced the BA initially to help the Proposition PM to dedicate most of the time to the customer-facing product. With two PMs we will also face a similar problem, although it may be less impactful. In this scenario, the Proposition PM is also relieved from supporting the operational process so the same goal has been achieved. The Systems PM is now responsible for the internal tools that enable the operational process as well as maintaining and supporting the operational process itself. We have now created a scenario where the Systems PM needs to dedicate some fraction of time to improving the internal tools and some fraction of time to supporting the operational process. Whether this is acceptable or not will depend on the complexity of the tools and how much work there is in the backlog for evolving the tools. If there is no bottleneck in executing the tools backlog and supporting the operational process, the PM Tag Team may indeed work well enough. If, however, the tools are not evolving fast enough to keep up with how the operational processes change, e.g. if the Proposition PM decides to add new features to the value proposition that require additional operational processes or a change of the existing operational processes, the Three Musketeer setup is to be preferred.
Conclusions
The following table summarizes the benefits and drawbacks of each approach to help you decide which setup to establish as a PM leader in your organization.
| Option | Feasible If | Potential Risks |
| PM Superhero | The product is in an early phase and still has to be validated in the market and/or the operational process to support the product is expected to be negligible. | During growth phase, the product may not scale and a single PM may no longer be able to focus on advancing the value proposition. |
| PM/BA Dynamic Duo | An operational process needs to be established and maintained and there are off-the-shelf tools available to support that process. | If the product evolves, off-the-shelf tools may be limiting the processes and adversely impact the degrees of freedom in advancing the value proposition. |
| Three Musketeers | The product is mature and operational processes are essential for further grows and do require unique and non-trivial tools for efficiency. | The company creates a dependency on in-house development to further scale operational processes. |
| PM Tag Team | The product is maturing and operational processes require unique tools for efficiency but their complexity is limited and investments into additional resources is tight. | The company creates a dependency on in-house development to scale and may fall behind if the complexity increases while the value proposition advances. |