4 Mistakes to Avoid as a New Product Executive

Hired as the new vice president of product management? Here are four mistakes to avoid when you first arrive:

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.

You could arrive on day one and decree that your list of product changes is the new priority. 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 alreadywell-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? Don’t assume your new company’s only missing ingredient is personal heroism. • There are already too many engineering projects underway? You may need to swing a cleaver, not another marketing requirements document.

2. Don’t postpone talking directly with live customers or prospects (and don’t stop once you’ve started).

The CEO has an opinion, as does the head of QA, every engineer and random people who tweet about your company. But opinions 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. Try to talk with one customer a day, take good notes and share them widely. Note whether the customer is in the target audience, what they like and would change, and how/why they use your product. Spend five minutes on the phone and 10 minutes more to post a summary. In two or three weeks, you can say “I talked with 20 customers, and here’s what I learned …” Suddenly, your list has the evidence to back it up.

3. Don’t get written 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 development team will treat your feature requests with suspicion (or derision) if you don’t know how the fiddly bits work. Consider sponsoring a lunch-and-learn series for your product team, with software architects sharing their wisdom. You provide the pizza and 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 the development team, sit in on a few support calls. And 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 until your development partners agree otherwise. Nothing sinks your credibility faster — both externally and within engineering — than unilateral over promising. Beware of customers and salespeople who relentlessly chase you down to plead 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. You can play the “I just arrived, I’m not sure, let me look into it” card for a little while. If you use your first few weeks at a new company to discover what’s really happening and what customers really need, you’ll be ready to speak with clarity and authority.