Here are some mistakes that I expect most first-time product managers to make – even after coursework, certificates, and online tutorials. New product managers may have studied the daily mechanics of the product development process, but are typically light on soft skills, product strategy, organizational savvy, and market insight.
In your first six months as a product manager, you will probably…
1. Promise a new feature to a customer without running it past your team.
Especially in enterprise selling, the pressure on you is intense to say “yes” to whatever the big client is asking for, in real time, with encouragement from Sales and your execs. “How hard could that new feature be? Probably only a few days, and fits into the next sprint.” A big mistake if you and your team haven’t sized and understood it, since it’s likely much larger than it sounds and will certainly push something of similar scope down into the backlog. And will have to be maintained forever.
2. Generalize your first three customer interviews into a market segment.
It’s tremendously exciting to get out of the building and talk with actual users, or customers, or prospects. You take listen, learn, notes, draw customer journey maps, watch over their shoulders as they use your product. And these first three customers have a lot in common. You don’t YET know, though, which characteristics are representative of your intended segment – or if your segmentation is the right one. Try to hold off on major conclusions until you’ve talked with a dozen (or three dozen) prospects and can spot the outliers.
3. Confuse sales calls with customer learning/research.
When you’re on a sales call, your only job is to help close the deal. The sales team has pulled you in to address a couple of product/technical/roadmap issues for a near-to-signing prospect. Your job is to help them get to YES without making unplanned commitments. (See #1 above.) Sales calls are not the moment for big-picture, open-ended research questions. (“What problems does our current product not solve for you? Would you rank these possible features for next year’s release?”)
Research discussions should be low pressure, exploratory, leisurely and humble. You’ll need to set up talks/calls/meetings with current users (outside the renewal cycle), target customers, lost prospects, etc. And do as little talking (i.e. as much listening and learning) as possible. Take notes, be appreciative.
4. Believe your own marketing/selling materials about why customers use and love your product.
Marketing has simplified and homogenized testimonials from actual and imagined customers, then supplemented that with positioning and dreams. Some of this may have originally come from you. Don’t breathe too much of your own exhaust fumes and don’t believe in a marketplace as simple as Marketing describes it.
5. Announce that you’re “CEO of the product.”
Nope. You don’t have hire/fire authority over your development team, or control over the R&D budget, or the power to change commission structures for your sales team. You have responsibility and influence, but very little authority. So sounding self-important can antagonize the people who directly add value: developers, test engineers, tech writers, UI designers, dev ops teams, sales engineers…
6. Tell engineers how to solve a technical problem.
Don’t. Engineers are hypersensitive to lowly product managers telling them how to do their jobs. Focus on framing problems correctly and getting the smartest folks solving them. (Hint: not necessarily you.) Even if you think you know the best answer, or used to be a developer, find humble ways to suggest possible approaches rather than pushing your solution.
7. Postpone meeting your internal counterparts.
It’s easy to fall into a daily engineering-focused routine, and respond only to other people who demand your attention. Folks who need your help will somehow find you. No need to socialize with other functional groups.
In order to succeed, though, you’ll need help from your equally busy peers in Marketing, Sales, Support, Sales Engineering, Finance and elsewhere. You’ll be swapping favors, sharing information, demystifying processes, preemptively solving problems, and generally bailing each other out. As the new kid on the block, they may expect you to come to them.
8. Confuse process steps (stories, tickets, releases) with market success (renewals, revenue, customer love).
Someone following you around all day could think that your job is to write user stories and join standups and create financial forecasts. But that would be confusing output with outcome. Your user stories have to reflect an overall strategy for making users happier (not just be well written); you join standups to address blockers and keep the team focused on what’s most important (not just to say what you did yesterday); you build forecasts as one tool for driving consensus and defining the economics of your product (not just as a launch checklist item for Finance). Your goal is deliver more joy to customers and more revenue to the company, which is the long-term outcome of hundreds of good decisions. You’re paid to think coherently and make good evidence-based choices, not just follow a CSPO process map.
All of this is why I strongly prefer to hire product managers with previous experience. But that’s not always practical. So let’s consider this from the hiring manager’s perspective (probably a Director or VP of Product). She’s just brought on a first-time product manager, anticipates all of the above, and wants to minimize the cost of learning. She’s also noticed that most of these mistakes are about soft skills and strategic thinking, not daily process steps.
Our product leader might:
- Make an explicit training/mentoring plan for her newbie
- Jointly create 30/60/90 day goals that include customer research, cross-functional introductions and priority-setting
- Assign a senior product manager as mentor
- Schedule time every week for discussion, problem-solving, mentoring. Provide fast feedback (especially in the first few weeks) on what’s working/not working. Focus on behaviors and deliverables and communication styles, not on personalities.
- Suggest a Myers Briggs workshop or other personality inventory training
- Start on some small/quick deliverables, and then move toward larger/more strategic work. No need to dive into the deep end of the pool first.
- Avoid hiring a whole team of first-timers: weigh previous product experience heavily in the interview process.
SOUND BYTE
What we do as product managers is hard, and generic third party training isn’t sufficient. We have to recognize the breadth of the role, evaluate our new hires for personal development areas, plan on lots of mentoring, and plan for typical mistakes.