The Startup Product Manager vs The Corporate Product Manager
There are many Product Management blogs out there that champion product managers as “mini-CEOs” of their company. That may be true at small-startups but much more questionable at large corporate companies.
Having PM’d at my own small company (GMAT Pill) and at a large corporate tech company (Expedia), I’ve witnessed some key differences to help give you some insight into the lifestyle.
Influence vs Authority
The number one thing I noticed when I moved from start-up to corporate is that the corporate Product Manager has no authoritative power. Only influence. Influence requires a lot of conversations and a lot of explanations. In a typical technology company structure, PMs work with UX and Dev leads. Sometimes there are PM/UX meetings, sometimes PM/Dev meetings, occasionally there are PM/UX/Dev meetings. In each of these meetings, there can be a lot of pushback or additional questions asked that weren’t brought up before.
For any typical product feature request, UX push-back could be, “Do we have any research that can guide us that [feature X] would indeed help us address [problem Y]? Is [feature X] done in this particular manner the optimal solution or is there a better approach? Would we be able to measure a key success metric?”
For any typical product feature request, Developer push-back could be, “Do we have any visuals or specific examples for what this might look like? Is this indeed a high priority item that has business impact for our team? Do we have all the requirements filled out for this request in a card?”
Those are all great questions. And to be clear, UX and Developers are experts in their respective fields. Product must defer to those groups for guidance in those areas — that guidance often can shape the original feature request. In the end, through a series of such conversations, the team will (hopefully) have solved the right problem with a well-thought out solution.
At a startup, the smaller the company, the fewer such discussions/push-backs there will be. Generally a few key people think about all the above questions, and then they will just execute. Sometimes it doesn’t even matter if the proposed solution is the best one. It just matters that there was some solution.
This is particularly the case with startups tackling problems in new areas and creating new/unique solutions for them. In such cases, execution matters more than precision. Speed-to-market and fast failing help the team figure out whether there was product-market fit. No amount of user research or elegant infrastructure (alone) will help startups explore the new territories of the Wild Wild West — the best measure of market reaction to a new product that has not figured out product-market fit is to just test it on the market and, using a lean approach, take the feedback and make the product better match the market and the user. Given the “rush” that startups are in and given that most startups are experiments (>99% fail, some manage to get funded), time will tell whether the execution done was precise “enough” to warrant a startup to successfully grow.
At a larger corporate company with a brand reputation at stake, precision takes priority. Most corporations cannot afford to risk their brand with a series of highly visibly failed experiments. It affects brand perception, it impacts customer trust and repeat rates. As such, it becomes paramount that large corporations spend the extra time to solve the right problem with the best solution. Laser-focused precision.
Because of this difference in priority of “speed to market” vs “precision”, the nature of how a Product Manager at a startup vs corporate interacts with the rest of his team is sharply influenced. A startup product manager may interact with just a few colleagues before making a decision. A corporate product manager, on the other hand, may interact with a wider variety of colleagues from several contacts in the product organization, product marketing managers, project managers, development managers, user experience/interaction designers, and other stakeholders. In a startup, some of these roles may be condensed into the same role, thus avoiding management coordination and leaning toward a more authoritative role that favors speed. At corporate, the product manager will need to manage across teams and somehow find a way to have all the right people in the same room at the same time (or at least, on the same conference call). In these settings, the PM will lean toward an influential role that favors ‘precision’ in terms of group consensus and a group decision. The tradeoff in either of these roles is of course speed vs precision.
Which one is better? Well, that depends on the nature of the product and the maturity of the company.
Precise Measurement of Success vs Directional Success
Naturally, large corporate companies have more resources and a history of revenue, enabling them to fund teams of product managers and analytics teams to measure the success of new features. Startups don’t have this luxury. They are often under the pressure to see growth in whatever form that may come. So when it comes to measuring the impact of a new feature, its directional and rough estimate impact matters more rather than distinguishing between a 5% vs 8% impact, which is considered more of a local maximum problem to solve.
The benefit of precise measurement of features (often done via an A/B test) is that it provides hard data and colorful insights into all the key metrics. There is no dispute. There is no second-guessing. The data is the data and the results speak for themselves. If a feature sounded cool and got the support of all the top folks in the room — but the results show a clear negative impact on the final success metric, it’s going to be shutdown. There is no room for error. The data gleaned can also be documented and shared for other groups’ benefit. Say another PM at another group wanted to test out a similar feature on another product. That PM could point to the results of another test and use that as confidence that his own test would probably succeed —thus learnings made can be leveraged for the benefit of the whole organization.
To be completed soon…check back again.