A Business Product Manager on Learning to Code
Completing the PM Trifecta in: Business, Users (Design), and Technical Expertise
The PM Trifecta
Take a cursory look around the PM literature world, and you’ll quickly find out that there is a general consensus that there are really only 3 types of product management:
- The Business PM: The grower. She knows the company, works primarily on business development and marketing, and describes herself with the words hustler, growth-hacker, saleswoman, and maybe even amateur psychologist. She’s the one that had that viral loop idea that gave you your hockey stick growth and she’s the one that keeps asking the question: “How do we grow?”
- The User PM: The designer. He’s focused on UI/UX, has some artistic and drawing credentials, and bases his thoughts on workflow and anthropological principles. He has a background in either design, education, or psychology. He’s the one that causes your users to email haikus of thanks to your team and makes the fanboys swoon. He’s the one that always asks: “How will this make users feel?”
- The Technical PM: The builder. He knows how to code, as in give him enough time and he can create your entire product himself. He knows your product inside and out, can manage your technical team flawlessly, and probably doubles as your CTO. He’s the one that plans out your technical roadmap, consuls you about scaleability, and has the best sway to make sure things get built. He’s always the one asking: “Can it be done?”
The general consensus is that all 3 types of Product Managers have their place in the world. Most accept that the Technical PM is needed in the beginning when the product needs to be made and everything must be assured to be possible. Once the barebones architecture is laid out and the hardest of technical development is passed, it’s said that then is the User PM’s turn to assume the reins. At that point, the User PM works with the design team to turn what was just a strictly functional product into a pleasantly useable service. In the end, it finally switches over to the Business PM who looks for ways to introduce the product to the market and find ways to generate revenue.
That’s however not what most companies do. They by nature hire the one most fit for their current stage, and then pray and hope that the one they choose will be able to pick up the pace and figure out how to perform the other parts as they come. Even the explosive success stories of Silicon Valley fall into this trap. Rather than diversifying or alternating the leading philosophy of each product through their natural lifecycle, the companies dig in their heels and isolate one aspect to be great at: Google hails itself as the Mecca of Technical PMs who create amazing and new fantastical products, Apple embodies design culture and leads the look and interaction of the products of the future, and SalesForce epitomizes business thinking in their relentless success in enterprise sales, customization, and innovation.
Why We Need Change
Contrary to their incredible success, that’s not the best path to go. In fact, the ability of those companies to succeed so dramatically even though their focus was on but one type of PM philosophy is really just a testament to the greatness of their executive leadership and recruiting process. It is by the 1000x game-changing nature of their product and amazing caliber of their employees that they were able to offset the incongruencies caused by the mismatch between their product stages and management philosophy.
Consider this, Google utilizes its treasure trove of revenue to give its engineers the opportunity to create thousands of independent projects. But how many of these projects have you heard about? What’s the percentage of the ones that succeed from the total? Is it possible that the percentage of successful ventures could be dramatically increased if there were bigger focuses on UX design and growth viability from the start?
Let’s look at SalesForce. The service’s ability to put all my leads and business development resources into the cloud has been a godsend. But some more thought could be given to the UI. I understand that it’s a professional business product, and the service really has been tremendously helpful, but I could’ve known those two a lot earlier if my introduction and first encounter with the UI didn’t prevent me from using it until I caved a couple months later. How much faster could they have grown if that wasn’t an obstacle? Now that they’re also releasing new products, how much greater can user adoption be if they were more UX friendly?
It’s Nobody’s Fault, But Something’s got to Change
Unfortunately, most startup can’t afford to and rightfully don’t want to switch their PMs repeatedly throughout the product lifetime. In fact, that would be a major Faux Pas as employees start to wonder about what the constant personnel change means about state of the company. The company and product would suffer from the consequences of a violently volatile product philosophy as the company culture goes from engineering-focused to design-based to business-faced, while at the same time be forced to undergo much larger investments in recruiting.
But if companies can’t and don’t want to alternate their PMs, then what’s the solution? If we can’t have 3 PMs one-at-a-time, is the reverse possible?
1PM three-at-a-time
That’s ultimately the thinking that we currently find ourselves at. Technical managers are now struggling to supplement their design and business skillset. Design PMs are expanding their coding expertise and reading viral marketing books. Business PMs are getting in touch with their inner designer and are learning to code. PMs everywhere are rushing to make sure that they complete the trifecta, so that they can remain applicable and ahead of every step of the product.
But is this actually possible? Elon Musk, whom I’ll regard as a PM even though he is a CEO, has theoretically achieved all three sides of the trifecta. He has an intense depth of technical knowledge in the very product he builds. He has renown and insane standards for the meticulousness of design which he demands from every Tesla model. He’s created by far and large the most unique of car campaigns we’ve seen in the last 20 years. But beyond the fact that most people wouldn’t compare themselves to Elon Musk, we also have to be careful to not confuse result with direct effect. For one, how much of what happens at Tesla is a direct consequence of his action and not a result of prior success? Though Tesla does have impressive marketing for its design and quality, it’s branding at the end of the day is the man himself and what he has come to embody. Are you really buying the car because of the amazing pure-car related marketing you’ve seen about Tesla? Or are you buying it because you’ve bought into Elon Musk and his vision for the future? To be fair, they’re both marketing: but one is deliberate and the other a very fortunate consequence.
So then does that mean completing the trifecta is impossible? I’m sorry to say, but I don’t have an answer to that question. My personal background is in business and psychology, and it wasn’t until my foray into startups that I had really begun to really explore the deeper nuances of design. It wasn’t until I had my first experiences negotiating development timelines that I even started considering boosting my technical credentials.
Founders and success stories will tell you either of complements or solo hustle: to either seek a technical/business/design co-founder or partner to supplement you in the areas you lack or to put your nose to the grindstone and learn it all yourself. Go deeper and some niches of the Valley crowd will even begin to say that there is no trifecta: that only the technical expertise matters and the other two can be easily learned.
That, I can say without a doubt, is not true. Though I’m not positive on whether or not a perfect trifecta can be held, I can say with confidence that each leg of the trifecta exists only because the PMs of the leg have such a dominant and unique philosophy. Philosophies of which can be learned, but may not be able to coexist with others. Advocates of the pure technical PM like Amazon underestimate the difficulty in introducing a new mentality. How difficult is it for a marketer to also adopt the mind of a coder? How about a designer trying to think like an investor? Possible definitely, but the duration required can’t be determined and repercussions to their existing mentalities would occur without a doubt.
In Goes One, Out Goes the Other
Therein lies my conundrum in deciding whether or not it would be fruitful to learn to code. I grew up with a business background, but I became design-oriented as a millennial tech user who coincidentally had an innate interest in education and psychology since childhood. With just two perspectives I can already see my priorities and mentalities vie with each other for validity, not to mention how difficult it would be with three. To make matters worse, as an ego-invested individual, I may not even really have two as my belief of possession cannot be without bias.
Some might take this mental struggle as nonsense: “People only have one voice inside their head after all. The voice of each leg will naturally merge and meld until it’s just one encompassing mentality with the best of all views.” But speak to a humanities major about engineering or vice-versa and you can quickly see the issue. There are very real difficulties in comprehending perspectives you’re not used to, not to mention the additional obstacles that lay in consciously fostering such perspectives while preventing any contamination to and from preexisting beliefs. There is a reason why one of the commonly and easily accepted cognitive myths is the left brain-right brain misconception: it is because we can all relate to how difficult it is for ourselves to think within lines we’re aren’t familiar with.
My answer is a compromise. I don’t believe that I’ll ever be able to fully adopt the engineering mindset of a full-time engineer. I don’t want to. Whether it is fear or procrastination posing as fear, I want to hold onto the business thinking and creativity that comes from the vagueness and blurred lines of humanities. Yet I still want to be able to continue to lead technical teams in development: and if the chance comes, I want to be able to spearhead the validity and creation of any new features I might conceive from my business and design perspective. I may be greedy in my wants, but I still want to be smart in my greed.
I believe this is the true trifecta for PMs to shoot for. Though the PM of legends may be able to drift in and out of every single team of the company and lead by example, the real PM learns to rely on the leads of those teams. The real PM knows enough outside of his expertise to contribute meaningful conversation and direction, but at the end of the day, is comfortable in acknowledging that there are areas out of his forte.
PMs who shoot to become experts in all three wind up as experts of none. They may gain experience and expertise, but they trade away their time and more importantly, the edge of their focus that made them unique. After all, the “M” in PM stands for Manager. The manager’s goal is to lead and know when to let others lead, not be an omnipotent employee whom renders all others moot.
Hope you enjoyed reading my post. If you click the green ♡ below, it’ll turn full and warm and really appreciate your acknowledgement! Give it a try :)
