Category Archives: Uncategorized

Product Managers, turn a weakness into a strength

Tai Chi

Product Tai Chi

Much to my chagrin I do not code.  Somewhere in the archives of my brain is some C++ I learned back in the stone age (late 90′s) but that’s about it. I certainly understand the value in knowing how to code at least at a basic level as a Product Manager.  I just haven’t taken the time to learn yet.  Well I should say I’m trying to learn and so far I’m pleased with the process on Codecademy.  I have a long ways to go however.

While it’s debatable in many circles I personally think this is a huge weakness of mine.  It’s so much harder to have a deep understanding of what it takes to build an application, how all the pieces fit together, and what it means to maintain web based software when you don’t have a fundamental understanding of it.  Personally I think I’ve done a reasonably good job understanding enough of the building blocks and high-level components that I can at least get by on that front.  The challenge goes beyond just the technical though.  Developers, especially the good ones think differently.  It’s much harder to develop trust and engagement with developers if they know you don’t understand what they do.  It’s not impossible but it certainly means you often have to work harder to gain their trust.  Honestly it’s hard to blame them.  In most cases developers don’t actually report to the Product Managers on their team (or at least they shouldn’t in my opinion), but 9 times out of 10 the PM is the one deciding what they will work on from one week to the next.  PMs set the priority for what the team is working on and thus what any given developer is engaged with.  In the best cases the PM is engaged with each and every developer on the team working through problems on a daily basis.  Would you want someone guiding you that you didn’t think understood what he or she was asking you to do? Probably not.

Here’s the rub.  The fact that I don’t know how to code is a tremendous strength in my particular PM space.  For the majority of the past 10 years my customers have been marketers.  I help to build products for marketers to get their job done easier.  In my current life this idea of making marketers lives easier has never been more important.  We strive to help marketers be amazing in a changing world where often the old skills that made them amazing marketers originally don’t apply anymore.  We build software products for people trying to succeed in a changed world.  In many cases they aren’t technical people.  They are smart, driven and amazingly competent, they just grew up in a marketing world that hasn’t provided them with the skills to succeed.  So they turn to people like HubSpot to help them.

Developers do not think like marketers.  Developers are problem solvers at the core.  At least the good ones are.  There is nothing more satisfying to a top-notch developer than solving a challenging problem.  Developers love to think.  The goal for a developer is a solution to the problem, the more elegant and straight forward the better.  For many developers simply having a way to do something is enough.  I can’t tell you how many conversations I have had with unbelievably awesome developers that go something like this.

Me: “Customers are struggling to understand how to make X work”

Dev: “They just need to click that link and configure their settings the first time they log in and it will work fine. ”

Marketers unlike developers are generally not problem solvers (yes, yes I know this is a gross stereotype that doesn’t always apply).  Marketers are goal oriented.  They are looking for the shortest easiest path to accomplish their goal.  They want to finish this thing so they can move on to the 133 other things on their plate, before they get assigned 57 more things.  They don’t want to have to think because they don’t have time to think. This mentality does not lend itself to problem solving.  Stepping back for a minute to think about how to solve the problem at hand is a luxury most marketers don’t think they can afford.  So when they hit a challenge they skip it and move on to the next thing.  In many cases this could mean in a split second deciding this app or this piece of software is just too complicated for me to use.  They quit your software before you never even had a chance to show them how magical it will make their lives.  The marketer is staring at the page for 30 seconds looking for the answer to their current headache.  It’s not obvious so they bail.  They don’t want to go hunting around for the solution because a) they don’t have time and b) they are scared they are going to screw something up.  They aren’t problem solvers.  Remember the customer in here?

Product Design Analogy

That’s a marketer. Although most developers I know of would at least make the swing work but you get the point.

Developers aren’t scared to screw something up because they know they can fix it.  “It’s just software, anything is possible.” Marketers are petrified of screwing things up because they have no idea if they can fix it.

So the interesting thing about developing software for marketers is you have to have people on your team that can think like marketers.  You have to be able to empathize with their daily challenges but you still need awesome problem solving developers on the team.  You need someone that can straddle these two worlds and help them communicate.

As an engineer by training I like solving problems, but I’m not a software developer.  Oddly enough the challenge of not knowing how to code has helped me to think like the marketers we serve.  Having a deep empathy with your customer base is impossible to over estimate.  I would fail miserably as a PM at Github because Github’s customers are developers.   By the same token I’ve seen really powerful pieces of software fail miserably because the customer just didn’t get it.

That said … boy do I need to learn to code.

Don’t hate the player or the game

MBA Ninja
Hating MBAs is in fashion these days. I’m sure by now you’ve heard of Guy Kawasaki’s famous adage.

For a rough approximation of your valuation, circa 2004, you can also use Kawasaki’s Law of Pre-Money Valuation: for every full-time engineer, add $500,000; for every full-time M.B.A., subtract $250,000.

Every developer I know that wants to start a company thinks this is the greatest formula ever developed.  Truth be told it’s pretty amusing and probably not far from the truth.  As I’ve said before there are no absolutes.  To make this a little more accurate I’d make two substitutions.  I’d replace Engineer with “productive value driven employee” and I’d replace MBA with “overhead employee”.

Recently the CEO at my current employer made some comments about the value of MBAs.  Now it should be noted he’s got an MBA himself and met his co-founder in business school.  He essentially said don’t bother getting your MBA unless you can attend a top-10 business school. He went on to explain, the most valuable things you get out of business school are pedigree and network.  Sure you’l learn a few things as well but you can learn those things pretty much anywhere.  I actually agree with this statement for the most part and have discouraged a lot of smart people from pursuing an MBA for the sake of the degree.  The rub on this sentiment is that there are about 20 schools that can legitimately claim to be top-10 B-schools.  It just depends how you rank them and what criteria you use.  This is one fundamental flaw of the MBA.  It’s so broad and so obtuse that it’s very difficult to quantify it’s value directly.

I actually think I got a few other things out of my MBA.

  • I learned how to work within and lead teams.  At Michigan there is a heavy focus on group based learning. In your first year nearly everything was group based assignments.  In addition groups tend to be assigned groups.  Like “in the real world” outside the ivory MBA towers you rarely get to pick your teams.  At least the entire team.  I’ll be the first to admit that the DB factor (douchebag factor) is very high in business school.  I mean astronomically high.  So this means you have to learn how to work with both insanely smart driven people and massively arrogant douchebags.  Successfully navigating this challenge is a skill I’ll carry with me forever.  The world is full of douchebags and I am prepared for them.
  • I learned how to evaluate a business strategically.  Thinking about the decisions you need to make and how they will play out over the next 5-6 decisions is incredibly important.  It can also be incredibly daunting and lead to stagnation in the startup environment.  So it’s incredibly important to know when you need to step back and think about where you’re going. It’s equally important to know when you just need to get shit done.
  • I learned that in the end it’s all about the numbers.  Actually I only partially attribute this to business school.  My undergraduate Science and Engineering education contributed pretty significantly to my comfort with numbers.  In business school you learn how to apply this to well … business.  It’s not about just reading balance sheets and cashflow statements though.  That you can learn anywhere.  It’s about knowing how to break down a decision into the core quantitative impact.

I attended business school with some of the most impressive people I know.  For instance my friend Grace who is putting her value destructing MBA to work building her own business around a passion she and her husband share. On the other hand there’s a few folks I had the pleasure to cross paths with that I hope stay under what rock they crawled back to after the MBA.

In the end, MBAs are like all people.  There are those that add value and those that erode value.  There are plenty of caustic engineers out there that are just as toxic.  Just because engineers have the magic keys to the castle, the ability to write code, it doesn’t mean they’ll inherently add value.