This essay captures some of my thoughts on how to manage software products and teams effectively in a scaling environment.
In the past four years I’ve worked with three CEOs at variable-sized software companies. During this time I’ve continually reverted to the same core principles taught by seasoned entrepreneurs, product executives, and management consultants. My product management (PM) doctrine employs a hybrid of product management, project management, and management consulting principles to ship products from ideation to 1.0 and beyond.
Understanding the Product Manager Role
Defining a product manager’s roles and responsibilities is difficult. Job descriptions varies from company to company, and the role inherently works with several departments. As a result, companies often intertwine the expectations of project managers, program managers, product designers, and product managers.
At its heart, product management is a cross-functional role that bridges the stakeholders, R&D, sales, and marketing personas. They fill the intra-company departmental gaps and do so by speaking as the voice of the customer.
Defining the Product Team Structure
At the strategic level, PMs should work close with stakeholders e.g. senior management. This increases parity between the two to bridge gaps between company vision and actual implementation.
On a weekly level, PMs maintain a close relationship with customers either directly, or indirectly via customer support. A solid foundation with users allows PMs to ultimately build the product in the way that solves the latter’s pain points.
On a day to day level, PMs should work closely in trio with the technical leads (project managers) and the product designer(s). They help translate customer requirements into product requirements, while simultaneously ensuring that the end result is consistent with the company vision.
On a cyclical level, PMs should be able to educate the departments to succeed in their functions. Customer support cannot succeed in their role if they are not empowered with sufficient knowledge. Marketing cannot succeed if they do not fully understand the unique selling points and solutions that they are bringing to customers.
Balancing Cross-Functional Responsibilities
The aforementioned section alludes to a highly diversified role. Good PMs are able to successfully work with all these personas. However, it’s easy to overcommit to one department.
Great PMs are not only able to work with all personas, but avoid becoming too meddled in a single department’s daily operations.
For example, Rich Mirinov explains throughout The Art of Product Management:
It’s easy to get stuck at headquarters, chairing meetings and shepherding action items. Being important is habit-forming. In fact, the more you drive as product champion, the easier it is to be shackled with additional internal responsibilities.
Too long without a road trip, though, and you can lose that visceral sense of customer reactions. I call this problem “insider thinking:” losing touch with external success by over-focusing on the details of delivery processes.
When PMs sit in Engineering, they spend their time with engineers. Days are filled with detailed discussion of bugs, development priorities, release trains, and software bundling. Especially in the absence of Program Managers, PMs dive deeper and deeper into the product creation process. This leads to technically good products, but a marketing failure.
Engineering PMs know their features very well, but are weak on benefits and sales materials. They impress technical users at conferences, but don’t know how customers are using their products. They under-invest in competitive analysis and a compelling high-level story.
I found spending ~20% of my time (2-3 months out of the year) interfacing with customers as a sweet spot that enabled me to stay in-the-loop with actual realities. This time is aggregated via on-site customer visits, reviewing support and feature requests, talking with clients on the phone, or relying upon customer service/account managers to inform me of external drivers.
This time is invaluable and should not be dismissed. When losing sight of customers, we accumulate incorrect interpretations of how the world behaves. The customer is not you, and staying in the loop with them will invalidate our worldview. In a production environment, staying informed saves on switching costs and reduces fires and the stressors that come with it.
Pursuing the Right Market
Product management is analytical in nature. There are costs associated with building features, modules, products, or product suites. Good product managers should not only think about building the product right, but building the right product.
Few companies, especially those with a few hundred or less employees, have infinite coffers. Before development begins, PMs must assess whether to even pursue a product. Great PMs will occasionally recommend stakeholders NOT to move forward for a number of reasons. Examples: an already-saturated market, insufficient economic returns, high-risk low-reward scenarios.
Sometimes the best investment decision is to hold. I’ve witnessed two product failures costing nearly $2 million, undelivered promises to customers and over one year of headaches. At a certain point, reputation damage is even more costly and difficult to regain, especially when clients had entrusted you with a portion of their budget in lieu of an alternative product.
Handling Insufficient Resources
In a company or project with finite resources, the allocation of scarce resources will inevitably leave some people/departments unhappy. This will lead to complaints escalating up the chain of command, or at the very least questions about the decision-making process.
Most of these conflicts I’ve witnessed are between R&D (engineering, design) and Business (sales, support, marketing).
It’s best to recognize inter-department conflicts before they manifest. In other words, during the planning phase of the product, the trade-offs will become clear. PMs should recognize and note these scarcities, then either escalate to or engage in negotiations with the stakeholders and heads of each department.
I cannot emphasize enough how important this is. Eric Schmidt in How Google Works stresses the importance of being an “effective router” of information. A great PM will be able to channel information in a way that will be understood by the receiving party. Patrick Lencioni expresses time and time the importance of listening to the receiver’s concerns and doubts. This creates two achievable goals:
- People oftentimes simply want to be heard and reassured that their input was taken into consideration during the decision-making process.
- Expectations are set to avoid curveballs adversely hitting a team. Although some teams may be on the short end, they will appreciate the heads up and can prepare accordingly.
Next thoughts
There are too many points to cover in a single post. In future posts, I intend to cover the following:
- Performing root cause analysis on feature requests
- Non technical vs. technical PMs
- Rapid iterations vs. waterfall environments
- Balance between the product manager, project manager, and designer trio
- SaaS models
- Formulating processes
- Product manager and product success metrics
Andy Cheng 