Product Management Blog

It's 2012, But I Still Like PRD's

I know in the age of agile, things like product requirements docs are a bit out of favor but I still like them -- at least to help solidify the PM's thinking and facillitate some tough discussions. It's often easier to flesh out non-obvious misalignment when you walk folks through a good PRD and some nice mocks than agreeing on the strategy in abstract.

So here are some things I like to see in a PRD. You don't have to write it as a long doc, heck you can even use it as a check list but if you can't answer these questions quickly, you probably haven't thought through what you're building as much as you need to.

• Who's the customer? What do they say, do, think, and feel?
• What problem are we trying to solve? Why is it a problem?
• What does success look like (this is often best written as a "press release")?
• How does it work (best written as a few paragraph user narrative like "jane decides she wants to grow her business...")
• What are the key use cases? What use cases are out of scope for now?
• What are the key capabilities and features we'd need to build to support that (stack ranked P0-P3)?
• What are the biggest open issues (and include stake in the ground for answers)?
• What does the experience look like (low-resolution sharpie sketches).
• What are the milestones? How are we gonna avoid this becoming a never ending project?
• What are the key metrics to measure and goal against? What do we think success will look like from a metrics point of view?

Happy shipping :-)

-Tom

What makes a Rock Star PM Candidate?

We often talk about looking for rock stars as PM's and recently, my team and I have been talking a bit about what exactly we mean.  Our goal is to put together the best product team in the country and we really mean it so we've mulled over what specifc characteristics do we think help us get there?  (Previously, we used the "we know it when we see it" method but realized this was a bit too cowboy and probably resulted in misalignment of interview loops.)

Below are the qualities we look for and evaluate when interviewing PM candidates.  When I take a step back and look at the list, it's interesting to note that product management skills are only #6!

Curious to hear others' thoughts on this as this is a list in progress.  For those of you looking to land that sweet PM gig, feel free to use this list as a self-assessment tool.  And yes, it's incredibly hard to find any candidates who meet all the criteria so it's more an assessment framework than a checklist (hopefully you make offers to people who have most of it and potential to do all of it with coaching and development).

 

1. Nice, interesting team player

• No jerks, no a-holes, no backstabbers.  We believe in karma and good things happening to good people who work hard, play well with others, and deliver.
• Team player, can lead but can also follow.  Want's to see the TEAM win.
• Good sense of humor. 

2. Eye of the Tiger

• Do they want to win, have something to prove, and have the determination to make history (as opposed to just taking on another product job).
• Do they get fired up when they hear about all that’s broken at MCHX and say to themselves, I want to fix that.  Now.
• Do they get fired up when they hear about all that’s working at MCHX and say they want to be part of that. Now.
• Are interested in doing whatever it takes for Marchex to become a $1B company and realize that helping us reach that goal is the ultimate boost for their career (as opposed to promotions, titles, or org charts).

3. High Intellectual horsepower. 

• Can they understand complex topics in seconds (not minutes).
• Can they zoom in and zoom out multiple times in a single conversation.
• Can they challenge assumptions and offer new ideas based on creativity, inspiration, and market and customer insights?
• Do they have an intuition for focusing on the things that matter and suppressing the  noise?
• Can they learn new tricks, technologies, customers, industries, etc. in weeks not months?

The Quadfecta

Saeed has a great post about the different functions of product management and the need to chop it up into different specialists.

While I've seen this taken to the extreme (Microsoft IMHO has way too many people doing product management for a single product), I’d build on Saeed's point about overly broad PM job descriptions by suggesting sometimes product leaders get carried away with the “mini-CEO” strategy.  The risk of one great PM to do everything is that you undercover a product with a single “hero” PM when in reality, few people in the industry really _can_ do it all and even if they have the capabilities, there aren’t enough hours in the day to do it all.

We’ve found having a program manager and product manager co-located pair on each of our products has been very successful. We partner those guys with the engr manager and business manager and it seems to be a good set up for the 10-20 engineer products.

Check out Saeed's post here.

The Split Personality of a Product Manager

The job of a PM is pretty hard.  It usually involves performing a balancing act between a variety of demands.  Here are some observations, suggestions, and musings about this tension.

Your product's positive face, head cheerleader, and mini-CEO.

Everyone knows about this role.  This is the one where you have to rally the troops to _believe_ and beat the drum externally as well to show everyone your product is the bomb.  When the chips are down you gotta see the positive in it.  When things go well, you gotta milk it for all the morale, recognition, and resources you can get.  This role tends to come naturally to most PM's.

Beware of the Integration Siren

It's tempting to invest in integration projects as your Company's product portfolio expands and invariably starts to overlap.

Here are some of the things you might hear bouncing around your head, the hallways, or exec review meetings:

1.  Why do we have 3 teams working on the same thing?

2.  If that other team built a generalized service, couldn't you focus on what's unique about your product and get more to market faster?

3.   You should work on things that have greater cross-product impact, why don't you drive this initiative to integrate all the different Foo efforts across the Bar division? 

In a lot of ways, these are all super valid and compelling arguments and often they're right.  

Things like account creation, permissioning, charting components, email alerts, check out work flows, etc. can be very costly to reproduce as the number of core products which use these things grow.   However, there are plenty of rocky shores to navigate.  Here are some things to consider before you embark on your big integration journey.

Massive PRD's and How to Deal With Them

Below is a reader question and my answer as a guest post for the Ask a Product Manager blog.

I recently joined an organization that develops software for life sciences, a highly regulated industry. As a vendor in this vertical, we are constantly audited by clients for our quality practices in software development. We are about to launch a new product line and the question of Product Requirement Documents have come into play. Our Quality Management team has asked my team to continue carrying requirements from older product releases into the PRD for the next product release version. My software product management career has typically involved writing “delta” PRDs – the net-new features that are going into the product, rather than one large document that covers 100% of the new product’s functionality. This is the case where the PRD serves as an internal communication tool with Engineering and Marketing but also an outward facing document that may get audited by multiple clients. Has anyone worked with writing requirements that carry 100% of the functionality forward with each new software release PRD?

Henry Ford was Wrong...Customer Research Does Not Lead to Faster Horses

An ABS reader pinged me last week and asked me how much time I think PM’s should spend doing face-to-face customer research.  My short answer was ~15%.  Of course, doing customer research well involves what you do with that 15% time so I figured I’d share some more color.  In no particular order, here are a few things to consider when thinking about your customer research strategy:

 

• Unless you’re building a product for software product managers, accept the fact that you will always have a flawed understanding of your customers.   Customers are complicated and heterogeneous; the world around them is always changing. I can barely understand my wife and we’ve been living together since 1999.  Frequently question your instincts and spider sense.  You don’t need to second guess every decision you make…but probably every third one.  At a minimum, remember what the Gipper said about the Soviets, “Trust…but verify.” 

 

Ideation is Overrated, Internal Buy In is the Real Innovation Showstopper

Comparatively speaking, new product ideas are cheap.  It's buy in, execution, and timing that separate the doers from the dreamers.  As an example, here are times where I sucked at getting buy in...

• In 2004 at MSN, I unsuccessfully proposed an idea where we'd take people's IM status messages and publish them in a micro-blog format.

• In 2006 at Trumba, I unsuccessfully proposed an idea where we'd enable special deals where the more people purchased tickets to an advertiser's event, the lower the cost of the event (so people would get their friends to buy tickets).

• In 2009 at the Google, I unsuccessfully proposed an idea where consumers could search for and get daily deals emailed to them based on their opted in preferences and search history.

It's entirely possible that one or more of these ideas could have been a big success had we given it the college try.  Instead, these ideas died on the vine -- usually in one minute of a 1:1, a couple minutes before a different meeting got a quorum, or in a hallway conversation on the way to lunch.   Generating good ideas is only as important as getting buy in for them.  If you come up with ideas no one wants to act on, you're about as useful as someone who doesn't come up with any ideas (but you'll be a lot more frustrated and bitter).

Some tips for winning buy in:

Software Product Manager: You're like the CEO...but you're not. How to manage diagonally.

People often say being a great PM means thinking of yourself as the mini-CEO.

While I often give this advice as well, the reality is it's even tougher than it sounds because you usually don't have direct authority of a CEO. This is the part where people will advise you to be a great influencer, lead by example, and build relationships with the the engineers, QA, ops, marketers, etc. Also true, but incomplete.

There's another big challenge which doesn't get talked about enough among PM's.  And that is that there usually is a real CEO/GM/VP who actually owns the P&L and he has formal control over a lot of the people you try to influence.  Like Drago, he can totally make or break you. How do you build a win-win partnership with him?  

When Product Manager's Announce a Release on Facebook

I saw funny some funny fake FB walls featuring folks like Abe Lincoln and got inspired.  

What if PM's launched their products on FB and their team members were FB friends (and were in particularly open and snarky moods)? 

Hope you enjoyed this as much as I did making it.  FWIW, over the years I've been on the receiving end of all of those statements :-)  

In all seriousness, it's helpful to know how some other folks may stereotype PM's so you can better empathize with them. Remember, the buck stops with you but you're nada without _everyone_ feeling as involved, critical, and important as you are (perhaps making you first among equals).