How To Get A Job – Chapter 2

Reminder, part 1 is over here.

Before we depart on our grand job seeking adventure, let’s meet the cast:

The Hiring Manager – That’s the person you’re going to be working for. They’re usually very eager to make a hire because they’re understaffed and they need the help.  So they want someone to fill the role but they’re also very busy trying to do the role plus their own while also hiring. At the same time, they know that this person will reflect directly on them. That means they want someone who won’t make them look like an idiot. Your job with the hiring manager is to prove you can do the job well and you won’t embarrass them.  Also, never waste their time.

The Hiring Manager’s Boss – Every hiring manager has a boss who’s looking over their shoulder at their hiring decisions. This person won’t be directly involved in the day to day management of the team but they still want to be involved. In almost every case, this person wants the impossible. They want someone who will work hard, put in long hours, has an amazing pedigree, knows the market and the job before they’re even hired and will do all this for half the pay of anyone else. In other words, the impossible perfect candidate. You’re not that person, no one is. Which means the hiring manager’s boss will never say “hire them!” after your interview. That’s fine, you don’t need their approval. What you do need is a lack of a veto. That is, you need to make sure the hiring manager’s boss doesn’t say “don’t hire them” because that’s a death sentence. No hiring manager in the world goes up against their boss once they’ve made up their mind.

How do you do that? Mostly by impressing them with your skills and passion. Remember, they’re not going to dive into the details like your hiring manager. What they’re looking for is more of an impression of you as a person. So make sure you leave the impression of a hard working, incredibly passionate about the job and very knowledgeable candidate. We’ll talk more about how to do this later.

Hiring Manager’s Stakeholders – These are people who you will be working with day to day. So if you’re interviewing for a marketing job, these might be the other people on the marketing team, or someone on the sales team. Like the hiring manager’s boss, your main job here is to make sure they don’t veto you. You do that by making sure they feel good about working with you. Ask a lot of questions about how they do their job, finish every interview with a “so how does this position help you?” or something like that. Make them feel comfortable that you will make their job easier.

The Coordinator – This is usually an HR person but could also be an office manager. This person is in charge of screening your resume, which means they’re the gate keeper you need to get past if you even want an interview. Even after you get your interview, this person is still in charge of setting up follow up meetings, reminding the hiring manager that you’re waiting for an answer, putting an offer together and doing all the hard logistics work that no one else wants to do. Your goal is to show this person you have everything the hiring manager asked for in a candidate and also not to piss them off. The easiest way to not get a job is to annoy this person. They’ll make sure you never get another interview again. So learn their name, thank them nicely on every email and make sure they know you appreciate their hard work.

The Three Pillars of Roadmap Building

I’m in the middle of a roadmap exercise at the moment and it occurs to me that this is the most important project any product manager will ever do.  Sure, it’s important to write requirements and PRD’s, but those are side effects of your roadmap.  There will never be a more important task than deciding the high level projects your team will work on and the order in which you’ll bring them to life.

So what the heck does a roadmap need to do anyway?

Support Company Goals

Do you even know what those goals are?  Maybe it’s time for a little heart to heart with your CEO or general manager because you need to know in detail what the goals are or else your roadmap won’t support them.  Are you looking to get acquired?  Increase ASP?  Reduce churn?  Go after market share?  Increase profitability?  It’s probably some combination of these things but you and your CEO need to clearly articulate what your goals are for the quarter, year or multi year period for which you are building a roadmap.

Goals should be the first slide in your roadmap deck, with methods to achieve those goals being the second.  After all, a roadmap is meaningless without an explanation of why you’re planning the things you’re putting in these slides.

Address Revenue Killers

Revenue killers come in all shapes in sizes.  They could be that killer feature that the competition has and you don’t.  They could be a persistent source of customer complaint like slow performance that’s causing customers to churn.  They could even be things like a lack of an ecosystem or poor API’s that’s causing some of your deals to not close. 

Best source for these are going to be your sales people and your support people.  They’re the one who know why current deals aren’t closing and why current customers are thinking about leaving.  The problem is one of perspective.  Sales and support people are going to give you a lot of tactical detail “this customer left because they didn’t like feature A” or “this deal closed because competitor Z talked to them about feature 1”.  It’s going to be up to you to collect all this information so you can see the trends.

This is probably not a slide unless you have a very open minded management team and board of directors.  No one wants you to air dirty laundry in public and putting slides with titles like “why we lose deals” is a guaranteed way to start a really bad conversation.  However, even if you’re not going to put this on a slide, you should still have the information.  It’s going to come up when people ask you “why are we doing project A?” and the best way to answer that question is with solid data.  “Because we lost 20% of our deals last year to competitor 2 as a direct result of not having project A in place and I have the numbers and details here to show you if you’re interested” ends the conversation right there.

Provide The Next Big Thing

Addressing revenue killers is nice and all, but roadmaps are meant to be visionary.  They’re supposed to excite people and get them oriented behind a shared vision.  For that, you need more than just “we’re going to fix feature A and put in place feature B which our competitors already have”.  You need fresh new ideas and they need to be exciting.

What are those ideas?  That’s the part I can’t help you with.  These are different per industry.  Just remember that an exciting idea doesn’t have to be a huge project.  Sometimes little projects can still be exciting.  It all depends on how you position them and this is where you need to get your mind out of the engineering mindset and into the world of marketing.

Go talk to your marketing team.  Chat with them about market trends, announcements they’re seeing and press releases other companies are putting out.  Take a look at unrelated industries and what they’re talking about.  Read magazines and see what society in general is talking and what the hot topics of the moment are.  This is where your big ideas are going to come from, not from any bug or feature request tracking software you may have in house.

Sooner or later, you’re going to have that Eureka moment where you think to yourself “oh! what is we could…” and in fact, it may even be “wait!  We could do that and it would actually be really is if…” and that’s your big idea right there.

When you have those, put them in your roadmap in the same section as all those projects you have to address revenue killers.  However, the big new thing (or things) is what should have top billing.  It’s like a newspaper where the top story gets most of the page and the big picture.  The big new thing is the top story, everything else is a sideline.  Also, don’t get hung up in features.  Tell people enough so they understand what you’re building.  The rest can be found in the PRD.

The Big Picture

A roadmap really is a set of instructions for how to get from point A to point B.  The product manager’s job is to know where point A is, identify where point B should be and then draw a line between them.  Everything else is details.

How To Get A Job – Chapter 1

This is going to be chapter one of my mini book on how to get a job.  I’m posting it here because I want to make the information freely available plus it’s fun for me to publish each chapter as I write it.

This book won’t get you a job. Only you can do that. Any author, book or blog that tells you otherwise is lying. What this book will do is help you get noticed. It will help you that interview or that meeting that may lead to a job. It will help you not get ruled out before you even get a chance to show them how good you are. The rest is up to you.

I’m writing this book because I’ve been where you are. I’ve spent weeks and months looking for a job and seen first hand how frustrating it is to be ignored. I would try to invest time in my resumes, I would customize and tailor them to every job opening I saw. I spent hours creating just the right resume for that position and then…. nothing happened! They never got back to me, they never even acknowledged I was alive.

So I’d get angry and then I’d decide that I was wasting my time tailoring resumes and I should just go for quantity over quality.  I would send hundreds of resumes every week to every possible job I could find and then… still nothing happened! At which point I’d read some article about how I should be crafting individual resumes per job opening and the cycle would begin all over again. It was ugly, it was frustrating and it was extremely unproductive.

That was 13 years ago. Luckily, I did get a job, although it was no thanks to my job seeking skills. Since then I’ve switched job three times, I’ve led teams of dozens and I’m now a VP at a large tech company. Even more importantly, I’ve hired numerous people to positions similar to the one I was searching for way back then. Which brings us to the reason I’m here in my kitchen, trying to type quietly so as not to wake up my 1 year old daughter and telling you how to get an interview.

I’ve been hiring lately, a lot. Five highly paid positions in just the last 2 months. I’ve also seen a lot of really crappy resumes and approaches. It’s gotten so bad that I’ve written a few public rants about the quality of the candidates I was getting and how annoyed I was with the whole hiring process, but this time as the hiring manager, the person on the other side. That’s when I realized that these people who were sending me resumes were making the same mistakes I did 13 years ago. They weren’t making them because they were bad people or even bad applicants, they were making them simply because they didn’t know better, just like I didn’t back then.

So, since I need good people and you need a job, I thought I’d write down some thoughts on how to land that first interview and how to get me, the hiring manager, interested in you rather than just dumping your application in my deleted items folder.

Note 1 – I’ve vetted these ideas with multiple other hiring managers. So not they’re just my ideas. These are tactics and methods that every single hiring manager would recommend.

Note 2 – My background is in the high tech industry and specifically in start ups and small companies. These ideas are mostly applicable to other industries but not all. Government positions for example are completely different and will require skills that I can’t teach you.

Never Leave Them Hanging

I’ve hired many people and I’ve also fired a few and the worst thing you can ever do in either case is to leave things ambiguous.

If you’re going to hire someone, tell them that. If you’re not going to hire someone, tell them that too. If you’re still trying to make a decision, be open with them and tell them what’s going on. Remember, these are people you might end up working with or for. Don’t you want them to like the experience of working with your company from the very first step?

If you’re firing someone, don’t give them bullshit reasons as to why because you’re trying to make them feel better. You’re firing them, the reasons aren’t going to make them feel better. Just be honest, say what went wrong and move on. I assume you’ve already cleared this with HR so why are you now trying to fill the void with platitudes? Don’t give them a reason to try and ask you for their job back. You’re firing them, this is final so make it obvious and clear. Anything else is cruel and unusual punishment.

No one likes uncertainty, especially not when it comes to employment.

P.S. the same applies to people trying to sell you something and folks asking you out on a date.

Forecasting In An Agile Environment

One of the most common issues at Agile shops is planning and forecasting. Agile shops aren’t like waterfall shops where you plan a 9 month release in advance. In a waterfall shop, it’s very clear what you’re planning to release in 9 months (which is a bit untrue because I’ve never worked at a waterfall shop that actually forecasted accurately but at least they had a forecast!) Which means that product managers at an Agile shop are unable to plan out releases or build a detailed roadmap.

What I’m about to describe is a way to solve this problem through a bit of spreadsheet magic.

(Note – If you want to see an example of what I’m about to discuss, check out this Google spreadsheet)

First, Write Your PRD

PRD’s are your bread and butter. They describe the project you intend to build, the business problem it will solve and the functionality you intend to deliver. Every project that involves more than 1 or 2 stories should have a PRD. No exceptions! Yah, I know, you’re an agile shop and you just work with individual stories. Sorry, being agile is no excuse for doing a poor job as a product manager. Your devs might worry about individual stories but you need to worry about the project (or epic) as a whole. For that, you need a PRD.

Second, Write Your Place Holder Stories

Each PRD should include the stories you’re going to deliver. These need to be broken up into the smallest possible chunk of functionality that still provides value. So if you’re doing a project that will allow users to authenticate through a social channel then you need to have one story that says “User can authenticate through Facebook”, another for Twitter, another for Google+ auth, another for “user sees error message if they try to authenticate a channel already used by another user” and so on. Break it down! This is your job as a PM and it will make the devs job a lot easier.  Don’t just write a single story called “User needs to authenticate through social channels”.  That’s pointless.  You’ve told the devs nothing about what they need to build, you’ve told your stakeholders nothing about what you intend to deliver and you’ve made your forecasting job impossible.

Third, figure out your velocity

Velocity is a measure of how many stories you can complete each week (or whatever your release cycle is). Some companies measure velocity in points and each story could have a different point value depending on complexity, but the idea is still the same. You’re trying to measure how many units of productivity your dev team can produce in a given time period. Other companies will choose not to include bugs in velocity calculation or to exclude chores. That’s fine, I don’t really care what specific system you use as long as you use it consistently.

Fourth, figure out the average value of a story

Remember those units of productivity you measured in step 3? Now you need to figure out how many units of productivity an average story is. If you’re not pointing stories then this is easy, it’s 1. If you are pointing stories, just look at your last 100 stories and come up with the average point value.

So what do we have?

  1. A PRD that represents a project
  2. The number of stories in that PRD
  3. The average number of units of productivity your team can produce in a given release cycle.
  4. The average number of units of productivity an average story costs

Multiply 2 by 4 and you have the total value of this project. Divide by 3 and you have the number of release cycles this project will take. Now do this for every project you have in your queue and you can build a really accurate roadmap.

Pro Tips!

  • Estimate velocity by engineer (or by pair if you’re a paired development shop) – Doing this will let you accurately factor in things like hiring. Just make number of devs a variable which is multiplied by velocity per dev to get total velocity.
  • Split projects into done, in progress and remaining stories – This will give you a good feel for when a product will be complete and how much progress you’re making.

Questions:

  • How should I use this model with my ENG dept? First, let me answer how you SHOULDN’T use it. You shouldn’t use it as a stick to hold over their head and say “this is what you guys promised me! Where is it?!?” That’s a very quick way to make enemies which is something you don’t want in the ENG dept. You should make sure they see this as their shield. This is the tool that will let them explain to the rest of the executive team why it’s impossible to just “add a small feature that the CEO wants” or why it’s better to start with a small project as opposed to writing every possible story that a customer ever requested. This is their tool to show what happens when you don’t pay off tech debt and velocity per week starts dropping because it’s harder to write code. This is their tool to show people what they could do if they could get more engineers. For a smart head of ENG, this spreadsheet should be their best friend.
  • How should I use this with management? I would share all of this with management and be very open about what this means. They need to understand what features are in the queue and when they will be delivered. They also need to understand what levers they have to make things show up quicker.
  • Why do you have a 20% buffer built into this? Because stuff happens. You have a week with a lot of bugs, you have a minor unexpected feature request that you just HAVE to deliver this week, you have an engineer out on vacation. That buffer is your protection against the unexpected. Be very careful about eliminating it.
  • Can I use this model? Of course. The only credit I want is that you call it “The Wave Model”
  • Why wave model? What wave is it measuring? No wave. It’s just that my name, Gal, means Wave in Hebrew and I have a huge ego that I am trying to make less than obvious so I didn’t want to call this the “Gal Model”.

Note – Copy of spreadsheet is provided by permission from my current employer, SocialChorus – SocialChorus website

SocialChorus® powers tens of thousands of brand advocates – employees, consumers and bloggers – to experience, create and share authentic content about brands they love. We call this new marketing category Advocate Marketing.

Our award-winning Advocate Experience™ solution makes Advocate Marketing performance easy. We combine a comprehensive SaaS platform with a dedicated, expert team and best practices to deliver measurable social engagement with millions of people every month.

Leaders in every industry, including consumer packaged goods, retail, technology, telecommunications, travel, automotive and financial services have chosen SocialChorus, the recognized leader in Advocate Marketing.