I spent some time this week with an executive who’s taking on a VP Products (VPP) role for the first time. We talked at length about the unique challenges for a VPP, such as politely downplaying the hundred merit-worthy ideas arrive each day. He then asked a question that stumped me for a minute: what are some mistakes he should avoid on first arrival at his new company?
Hmmm. Pause. After pondering some of my recent VPP adventures, I came up with four:
1. Don’t recommend any product changes until you’ve been there at least two weeks, and have listened carefully to a lot of folks.
It’s easy to look at a product from the outside and make yourself an instant expert: jot down nine things that annoy you on first impression, sketch some killer feature extensions, re-arrange the interface, redline the FAQs. You could arrive on Day 1 and decree that your list is the new priority. (There’s a new sheriff in town, with a whole new backlog.)
Don’t. Premature reprioritization may cost you credibility. What if:
- Your product management team is smart, and has a similar list. They need your organizational clout to push for already-well-understood improvements, not another new list.
- You’re not the typical user. This target audience is younger, female, exclusively on Android, International, and constantly online. (If that’s you, then imagine the opposite.) Your intuition and experience may not be relevant.
- There are non-trivial technical or legal issues to overcome. (Perhaps EU privacy laws forbid broadcasting birthdays, or whatever your killer feature was.) Don’t assume your new company’s only missing ingredient is personal heroism.
- There are (very likely) too many projects already underway in Engineering. You may need to swing a cleaver, not another MRD.
2. Don’t postpone talking directly with live customers or prospects. (And don’t stop once you’ve started!)
There will be a lot of anecdotal non-evidence circulating about what customers want. The CEO’s brother has an opinion, as does the head of QA, every engineer, and random people who tweet about your company. All lack rigor, consistency, business justification, judgment and strategic thought.
Get a list of real customers (users, prospects, beta testers, whatever) and start reaching out immediately. You’ll get good responses with “new VP Products wants your opinion.” Try to talk with one customer a day, take good notes, and share (wiki) them widely.
Note whether your mini-interviewees are in the target audience, what they like and would change, and briefly how/why they use your product. 5 minutes by phone, 10 minutes more to post a summary. In two or three weeks, you’ll be the only one in the room saying “I talked with twenty customers, and here’s what I learned…” Suddenly, your list from #1 has some evidence to back it up.
3. Don’t let Engineering write you off as a technical lightweight.
Especially for computing infrastructure and B2B software companies, the engineering team demands product folks who can keep up technically. They have little patience for Marketing types, buzzwords, or mixing up compilers with composers. The dev team will treat your feature requests with suspicion (or derision) if you don’t know how the fiddly bits work.
Consider sponsoring a “lunch & learn” series for your product team, with software architects sharing their wisdom. You provide the pizza, and secretly learn what’s inside the box alongside your product managers. Also, if you can, use your product intensively; skim the technical docs; talk informally with dev team; sit in on a few Support calls. Wear t-shirt and sneakers on engineering-focused days. (Never let engineers see you wear a tie.)
4. Don’t promise delivery dates for anything, no matter how small, until you’ve gotten Engineering’s agreement.
No matter how simple a fix appears to be, assume it’s difficult (or depends on something that is difficult) until your Development brethren agree otherwise. Nothing sinks your credibility faster – both externally and within Engineering – than unilateral over-promising.
Customers and sales reps will relentlessly chase you down to plead (demand, cajole, negotiate, threaten, lobby, glad-hand, weep) for some improvement that “can’t be more than a few lines of code.” Listen and offer to investigate, but don’t make any commitments out of ignorance or shame. Promise a response, get contact info, and use this as another vehicle to learn your new product set. Remember, you get to play the “I just arrived, I’m not sure, let me look into it” card for a little while.
[Of course, all of this applies to a newly arrived product manager regardless of level – fancy titles notwithstanding.]
Sound Byte
Use your first few weeks at a new company to find out what’s really happening and what customers really need. Then you’ll be ready to speak with clarity and authority.