Why Product Management Is Easy
I track the term ‘product management’ on Twitter. You can see the results of that search term by checking out a handy tool called Tweet Scan. Essentially, whenever someone mentions the words “Product” and “Management” in a tweet, I get alerted on my cell phone by way of SMS.
I’m a nerd, but I find it interesting. And, yes - this turned in to a hella long post.
Recently, and you should see this if you look at the search results, I’ve noticed a couple of folks talk about how hard a job product management is. I wanted to make some points here about this, and hopefully put to rest reservations folks may be having about exploring the possibility of getting into the job, or maybe even continuing doing the job if they are already in the thick of it.
My take is: it’s not hard.
Now, I’m not a product manager in a big, massive company. I never have been, and if I were a betting man, I’d say I never will be. That being said, I do in fact recognize that there are differences in how product management is done at say, Microsoft, and how I’ve structured it in the past. This is just due to the nature of the size of the organization where the job is sitting.
So, keep that in mind. My take on things is really related back to 20-50 (maybe 100 or less) person organizations. Anything upwards of 10,000 or 20,000 person companies really boggles my mind. So, hopefully that’s clear.
I do in fact recall when I was first put into the role. It was exciting, but at the same time, really ridiculous. Not for any other reason than, I wasn’t working for a more senior product manager to kinda guide me a long and instruct me on what to do - I was in there on my own learning as I went. It turns out, this is ideal for me, but I recognize it’s certainly not everyone’s cup of tea.
This leads me to admission number 1: The job is damn near impossible when you first start. Actually, scratch that — it’s damn near impossible when you get 3-4 months in. This is because, at least from my experience, it takes people about that length of time to really wrap their heads around what it is they are supposed to be doing. And I believe this is where most would sink and maybe start believing, “this job is WAY too hard for me, or anyone, to really do.”
And that’s 100% true. The way the job can be defined, it is impossible for someone to excel at. If you think about needing to be “proficient in Sales, Marketing (specifically, messaging and positioning), have a strong technical knowledge, excellent project management skills, well-versed in strategic alliances, and have a good foundation in finance.” Yeah. That’s a little tricky.
Let me take some of the surprise out of this description - there is no one that is “highly proficient” or “expert” in all of these things. They just don’t exist. You will either get a “tech” person, or a “sales” guy / gal, a “marketer” or a “project nerd.” But all of those wrapped into a single individual? Yeah. Not so much.
Now, this is where people may start to get down on things. How could you possibly do a job where all of those things are important? Some may say, “this is exactly what I think it’s HARD.” OK, well hold on - I’m getting to why it’s not.
Yes. those things are important. However, in a position like this, delegating is absolutely critical. That’s why you will usually see the line about “leading without authority” associated to many product management job descriptions. Why? Well, I’ll use myself as an example.
1. Am I a marketing genius? Hellz no.
2. Am I a great software programmer? Ummm, far from it. I may know a little LISP and SQL here and there.
3. Am I great with numbers? If you asked my grade 11 accounting teacher, she would say, “HAHA. No.”
And so on.
But here’s the key - if you understand *conceptually* how these things work, and maybe more importantly, how they work together, you are doing the right thing. No one person can build a great organization - it takes teams of people to do that. So, let’s re-visit those questions above with some modifications to them.
1. Do I understand marketing and have great marketing people to work with? Yes.
2. Can I give flexible requirements and wireframes to the outstanding developers and watch them develop wicked code? Yes.
3. Can I ask the finance people I work with to help me track project budgets to make sure I don’t go wildly out of control? Yes.
At the end of the day, so long as I understand the critical nature of cohesive positioning and building brand equity and help play air traffic controller to make sure marketing can do it’s thing, I’ve won. I can completely let go and push. IE, “I can give you feedback and my thoughts on positioning this product, but I need you to write the words and deliver something cohesive.” If they don’t, that’s another issue entirely. But I think you get the idea.
OK, so that’s a big long “admission # 1″ type thing. Once you cross that functional expertise hump, admission number 2 is this: The answers are right in front of you. Sure your opinion will factor a lot into the initial product release / development / design - but use those around you to vet ideas and build some momentum (no “i” in “team,” etc…). Someone actually has to DO things, but gather feedback (at least internally if you don’t have users yet, and then put something out in to the World.
Guess what? You are going to get a lot of stuff wrong. But it’s not about right and wrong. It’s about common sense and building cohesive products. The answers are always there - you just have to know where to look and how to ask.
So, is product management hard? No. The trick is not being the best marketer, accountant, UI designer, developer, Sales person all rolled in to one. The trick is to make sure that features get built, marketing communicates them, support can answer questions, and Sales can sell.
All the job is is connecting dots and knowing where to look for the data you need to make decisions. Don’t get overwhelmed by all the noise.
Why Mahalo
One of the most frequent questions I get is: “why do you use / like Mahalo?” Well, I figured it was time to address this in some more depth.
First, those that discover (for the first time - and maybe beyond) that I use the product over Google are quite surprised. It’s almost like a “how could you abandon Google?” type response. Well, the truth is, I’m not. But we’ll get to that in a little bit.
Really, it comes down to believing in what Mahalo is all about as a product more than anything. Sure I use Wikipedia. Could I rely on it for day-to-day information? No. Sure I read a ton of RSS feeds, but can I rely on those to provide with answers about a bunch of stuff (really, anything) throughout the day? No. Does Google mesh both of those things (current + news) — yeah, kinda.
But not in a way that completely satisfies me.
Let me fill you in on what I deem to be the 2 secrets of Mahalo.
- It’s not trying to be all information to all people (Google)
- Their guide notes (shown in the screenshot below)
This little blurb of text provides me with Wikipedia type information, but in a fast and easily referenced way. This is especially true when you get to the homepage. This is human-monitored and managed information, folks.
So this should cover why it’s better than Wikipedia, even though Mahalo makes no promise to be a Wikipedia replacement. It it did, I’d surely be less interested. But I see these two things I’ve mentioned already as key time savers throughout my day.
Now, if you look at the screenshot above carefully, you’ll notice a section called “Help Build.” I’m not going to get in to the intricacies of the Mahalo Greenhouse. But certainly, one of the best ways I got hooked as a user was when they rolled out Mahalo Social. Yes, I contribute regularly.
I actually started, and contributed, several links to help build the product management page, as I’ve mentioned on this blog before. And you know what’s funny? I actually want to submit content. When I see a spelling error on a guide note, for example, I want to draft a quick message on the message board for that page to let the guide that created it know. Why? Because I’ve actually received timely responses that are well-spoken and seen results.
You don’t get this from Google. Mahalo knows it’s capital intensive to run a people-driven content business like this, but it’s imperative. Regular old, unimportant users like me actually get to see there is stuff going on behind the scenes and they really do care about the quality of the content they are creating.
One of the other great things is their browser plug-ins that make it drop-dead simple for shmoes like me to easily supply them with content.
Now, this is only the direct and immediate type stuff that you get when interacting with the product. And I can’t lie - I know there are certainly critics out there. Any product will have them. But anything that really saves me time and helps me to find the content I’m looking for quickly is a big winner in my book.
Oh, and how have I not abandoned Google? Well, for any page / search term Mahalo doesn’t recognize or have yet, they will show you Google results. Perfect.
Ed the Sock vs. the Shel Puppet
Loren Feldman is getting a lot of attention right now for creating the Shel Israel puppet. The videos are hilarious. Being the big fan-boy of Jason Calacanis that I am, I loved his current set of Mahalo interviews.
Watching these videos though, something kept ringing in my head. It took me a few hours to figure out - but I recalled a great source of humor from my childhood that the Shel puppet seems to channel in a great way - Ed the Sock.
As I’m sure most Canadians will remember, Ed was a hilarious (well, to most of us anyway) puppet that used to be featured pretty regularly on Much Music. I don’t really know what Ed is up to these days, but I thought I’d draw this comparison out anyway.
Ed, I’d encourage a trip to California, some meetings with Mahalo and Calacanis and give the Shel puppet a run for his money. Canadians need to represent.
The Importance of QA
I am in the process of hunting for a great senior QA analyst. That being said, I wanted to take some time to talk about how important QA is in the product management process; or at least, how important I view it to be.
In my experience, if you are able to find and bring in the right QA person, that’s really into QA (and not just using it as a stepping stone), they will have a strong / noticeable impact on your product as early as its next release. I’m not kidding. I was lucky enough to work with a very talented QA engineer / analyst while at MusicIP, and his work ethic and results were absolutely perfect for helping us with several key initiatives.
So, what are some of the things that I’ll rely on QA for? I’m glad you asked…
Primarily, you don’t want defects in your product. I view the role of QA to help identify and manage bugs, but also prioritize them and ensure they are getting fixed. This way, I can stay focused on planning the product and trust that when a certain set of users can’t do something they are supposed to, it will get taken care of accordingly.
So, this means setting up your QA team to succeed. And usually, that means metrics and objectives. The key metric I’ll look to that’s directly tied to QA is product quality. Essentially, this is an amalgamation of high severity defects throughout the product (1s, 2s, and 3s usually). A great QA person will derive these priority values by assigning visibility and class rankings to them. For example, how likely is it a user will encounter a specific defect? And, if they do encounter it, what is the likelihood of it completely hindering their product experience?
You need to have these checks in place in order to ensure what you are shipping (especially as it grows and becomes more and more complex) is of the highest possible quality.
Now, the other key aspect I look for in QA is sanity checking my requirements and making sure their associated test plan runs the gamut. I may state that a user “must be able to create an account” and that “the username and password fields are required,” but the QA analyst will take this one step further and actually determine all of the permutations (that either may or may not be documented in the requirements) development must cover.
In this example specifically, maybe the e-mail address the user enters is malformed. Maybe their password doesn’t match to the 6-character standard. When you are working on releasing code quickly, especially in an agile system, this type of coverage becomes crucial. I need that constant stream of discussion and feedback.
Essentially, I’m looking for trust - not only from the product team, but the QA team (regardless of wether they sit in product or engineering), the development team, the marketing team, etc… I want to develop the trust that the QA team will catch critical user flaws (hopefully) before requirements even get to development for implementation so we can work out the kinks and ensure they are as clear as possible.
Beyond this, QA can really help development too — with structuring automated test suites, tracking their results per build and really grinding out the processes to ensure maximum build effectiveness (especially when using continuous integration tools) and insist the quality is really high and stays there. They may also be able to help when running core A/B tests on a site to help determine if user’s are encountering critical flaws in one implementation and/or another and what the outcomes are of possible change.
Remember, the “Q” in the abbreviation stands for quality. That’s their job. It’s not to administer servers or to be an authority for developers. However, it’s one of the most critical jobs in an organization - especially one that is just building / starting out. If the product you are releasing is poor quality, chances are it’s going to get very far.
Bring in an experienced QA person early and really maximize their value as much as possible. You won’t regret it, and your users will thank you for it.
Staying Focused and Making Bets
I had a really great conversation today with a super smart individual. Whenever I can step away from a conversation / meeting knowing that I’ve learned something, it’s awesome. Today was one of those meetings.
One of the topics that came up was, with relation to a start-up, how imperative it is to do four things to give your organization the best chance at succeeding:
- Develop a vision and focus on it
- Place your bets
- Be heavily critical about the business
- Obsess about results
I know the term “vision” doesn’t always have the best connotations. I could easily see someone hearing the word and picturing those cheesy motivational posters hanging in SVP/EVP and C-level offices all over corporate North America. Take a look at the picture to see what I mean.
What I’m talking about is a very centered description of your business and what you are trying to accomplish. This isn’t a PHd or Masters paper here, folks. It’s a very clear and concise paragraph at most. You want something that everything else is aligned to - if you don’t have it, you are going to start spinning your wheels and going in circles; trust me on that one.
Once you have the vision (and yes, it can change - this is a start-up after all) you need focus. At the exclusion of all else, everyone in the organization must be 100% committed to executing that pre-defined vision. Your product roadmap must be committed to it. Your finance people must be committed to it. Your support reps, sales reps, etc…
If “really awesome / cool” product ideas start to seep into the culture, you’re sunk. Kill everything that exists that doesn’t support the vision and focusing on it.
Of course, let’s be realistic. You’re certainly going to want to assess whether your vision is attacking an appropriate market opportunity. If it’s not, that’s also a major cause for concern unless you know how to create new markets. That’s not entirely out of the question, but it is quite difficult.
Once these pieces are put together, you need to place your bets. You could be wrong. Trust me, it wouldn’t be the first time a start-up executed 100% correctly but failed due to external consequences (i.e., wrong market, wrong product, wrong timing, etc…). But if you can get something out the door that solves a problem for a set of people, are you light years ahead.
Again, and I can’t stress this enough, you very well may be wrong. Your board / investors have to be comfortable with the fact that not everyone hits a home run every time. Sure, take input - but don’t let things veer off course. Remember, you have to maintain focus in order to place a bet on the vision you’ve constructed.
OK, so say you get all of these things in place - what’s next? Well, you must be critical of the business. Let me repeat - “the business” does not mean “other people.” For example, you have an amazing quarter and are really rocking along (blowing away estimates, shipping stuff ahead of schedule, improving productivity, landing some key talent, etc…) how are you going to do better next quarter?
On the flip side, what if you have a horrible quarter? Don’t blame Jimmy in the mail room. Take ownership. Are you maintaining morale? Are you still maintaining your focus on the bets you’ve already placed? If not, you have some re-evaluating to do. Namely, identifying how things slipped off the rails during this time period. But always be heavily critical of the business. This dovetails into the next point…
Obsess about results. If you aren’t concerned with the results you are delivering, something is out of whack. If you can’t deliver the results you need to, change something. If you are delivering, see the previous point - heavily criticize the business.
Of course, this all may seem like common sense. I guess that’s kind of the point. It’s all the little things that really make the difference - and ultimately, being able to execute.
