Differences between product management in startups and enterprises
Incumbents have their own challenges
I started my product management career in startups and scaleups, mainly focusing on consumer products. When I switched career to being a product manager in an enterprise with 5,000+ employees, I experienced a lot of shock.
Product release life cycles seem much longer — usually it would take months instead of weeks to get an idea out in the market. The workplace seems more ‘political’ than a startup environment. People spend a lot more time doing ‘internal PR’ which are roadshows designed to get stakeholder buy-ins. The actual work of product management we read about in books and product conferences take up a much smaller percentage of my time compared to the effort spent on aligning perspectives and communicating benefits of what want to achieve.
And this is all before the actual product get into the hands of the users.
For some time, I wondered why these phenomenons are at odds to what product management ‘best practice’ looks like. How come there is so much overhead in doing anything? Isn’t product management about making product users love? If so how come product managers working in enterprises spend disproportional amount of time with internal stakeholders and wider teams?
Here are a few lessons I have learned over the years, hopefully you’d find them useful too:
Complex organization requires a different way of communication
You can execute fast with a company of 50. You just need to speak to a handful of people to communicate the release. It’s much easier to keep everyone in the loop in what each other is doing. Such communication can be informal too.
But to run a big business, you need more people. Aligning perspectives of these people and gaining their buy-in takes time. Delivering products in a global enterprise with 5,000+ employees requires a different ways of communication. It is common that before a project is incepted, the product team draws up a ‘stakeholder map’ following the RACI matrix, outlining who should be responsible, accountable, consulted and informed. When the enterprise is global, business units from different geographical regions complicate the picture. It’s common to form cross-functional working groups with these stakeholders to enhance knowledge sharing and gain buy-in.
Also, a larger organization with an established business usually have in-house Subject Matter Experts in their respective domains. These are typically people who know their business vertical very well and are able to identify opportunities and de-risk the product. Compared to a startup still validating product-market fit, having in-house experts who deeply understand the market opportunities helps improve chances of product success. Although these are not replacements for user testing with real customers, looping in experts early drastically de-risks the product release.
On the other hand, launching a product quickly but in isolation is often a way to fail quickly, which leads to the next point.
Speed-to-market isn’t always the winning factor
Marc Benioff, ex-CEO of Salesforce once said, ‘Speed is the new currency of business’. But this principle sometimes does not apply in a well established enterprise. I’m not saying that speed-to-market isn’t important. It’s just that it’s not always the only winning factor for product success.
We have seen over and over, a product that is launched later could overtake the product that went to market first. With established client base, deep industry expertise and deep pockets, an enterprise can often erode the first movers’ advantage of a smaller company. Such is the power of large-scale organized activity.
A key reason to launching fast is to test response of users in the market and then quickly iterate on both the user experience and the proposition. This is particularly useful for startups who are trying to create new market segments.
An enterprise, on the other hand, often launches new products to strengthen its position in existing market or expand into adjacent markets. A product manager in an enterprise can leverage knowledge and data that exist internally, and utilize real customer feedback in parallel. The end result would be a more considered product that fits with internal capability of the organization as well as user needs.
More internal competition for power and resources — more ‘political’
In a high growth environment such as a startup, there are plenty of opportunities for career advancement. It takes another funding round to expand the company so suddenly, you get to build and grow a new division! Growth floats all boats and startup employees are motivated to overcome differences and achieve a single goal of the company. In a failing startup, fighting for survival becomes the top priority that galvanizes all to focus on the turnaround.
Growth is usually much slower in an established enterprise. Since an established enterprise already owns sizable market share in their business vertical, there is substantial revenue generated by existing ‘cash cow’ business units. As a result most people are competing for this an almost static pool of resources. Department heads fight for budgets much more fiercely. Bargaining, negotiation, coercion, and compromise are a normal part of everyday life. Coalitions form around specific interests and change as issues come and go. Solutions arise from political skill and acumen.
The organization sometimes feels like a factory
Coordinating many employees across the globe is no small feat. Often we’d found that a large organization has more compared to a startup, where roles and boundaries are less clear.
The large organization often emphasizes organizational architecture, including goals, structure, specialized roles, coordination, and formal relationships. The structures are designed to fit an organization’s environment and technology. A larger organization allocates responsibilities (“division of labour”) more formally compared to a 50-person startup. They then create rules, policies, procedures, systems and hierarchies to coordinate diverse activities into a unified effort.
Employees — and product delivery teams — may feel that they are chess pieces that get moved around strategic initiatives decided by leadership. Autonomy mainly happens at a product level. If the enterprise is very hierarchical, product teams could even feel that they are not valued. If this happens, senior leaders in the enterprise have to address the issue by creating a more transparent and open culture and improving on vertical and horizontal communications across the organization.
Conclusion
Being a product manager in an enterprise presents a different set of challenges. What are your thoughts on challenges on building products in an enterprise?
