…and 5 more for the first month.
If you’re already a product manager and stepping in to take over an existing product (or parachuting in as a consultant), you need to find your feet quickly. Here’s my checklist for that first week:
- Meet in person with your key partners/stakeholders: VP engineering, development lead, marketing director, CEO or GM, adjacent product managers, sales director… Face to face, not by phone. Introduce yourself, ask what’s working/what’s not, and probe for simmering issues. Take notes, listen, be humble. This will be more opinion than hard facts, but gives you a head start on your own appraisal.
- Find (or create) the backlog. Every meeting will include a few “small” requests for things that “have already been committed.” Write them down, put them into the backlog, but don’t make commitments until you know the scope of the problem. “Thanks, that sounds reasonable. Let me look into it and get back to you.” Most likely, execs and sales teams and customers anticipate a decade’s worth of quasi-promises in the coming quarter. The #1 symptom of absentee product management is a haphazard backlog with dozens (hundreds) of urgent items.
- Start booking calls with customers ASAP, even if you don’t get to talk with them immediately. Pull a list of representative users – not just your top three customers – and ask for 20-minute phone conversations. (“I’m the new product manager for X, and want to get your input. This will help me serve the customer base better. I’m not in sales.”) It may take a week or two for these calls to happen, but get some requests out by Day 2. Block time for them on your calendar.
- Learn your product. If it’s an online service, create an account and carefully note any sign-up or workflow issues. If it’s a personal accounting application, load in some recent financial transactions. If it’s a developer-oriented API, scan the code samples. Read the manual. Write down a dozen things you might fix or change. You only have a few days to experience your product as a naïve user.
- Gently introduce yourself to the development team. Join some standups, grab lunch with random devs or designers, be a mensch instead of an MBA. LIghtly sell the value of product management, since they probably haven’t had good previous good experiences. (“Your time is really valuable, and we know how expensive interrupts are, so please route sales all requests to me.”) Position yourself as their champion.
And within the first month, you should:
- Have at least a dozen calls with live customers. Take notes, post them to the team wiki (or whatever), send a very short summary/link to the development team, and start to develop your own sense of what’s typical. This has a pair of benefits: you’ll be working from primary information rather than second-hand sources; and folks will notice that you’re working from primary information. Start saying, “here’s what I heard from customers…” instead of “here’s what I think.”
If you run an online service with user statistics, activity logs or sign-up information, crawl through the numbers enough to know what kinds of information exists. Have a strong opinion about whether your product is instrumented enough to make data-driven decisions. - Have (or locate) a preliminary product strategy. Are we targeting enterprise or small biz or individuals? Focused on increasing usage or sign-ups? Pricing for share or profit? Expanding internationally or investing domestically? If you just answer “yes” to multiple choice questions, you’ll be unable to make hard trade-offs. No strategy means no focus. And bottom-up story ranking never creates strategy or coherent products.
Dissect your financials. Most products are intended to make money, and that’s how executives keep score. Review your pricing, unit sales trends, and concentration of large deals. Figure out if you deserve a much larger dev team or should expect poaching. Know if your product is a star, a dog, or a zombie.
- Prep for a roadmap reset. I almost always discover that dates and commitments are far beyond what engineering can deliver. Socialize some reduced expectations, and collaboratively work out a more achievable plan. What really, truly has to be in the next release?
- Find a quick win or two. You and your team will need some morale boosters, even small ones. A small-but-cool feature shipped? A major sales win? Automated testing finally running? Celebrate something with the team, using “we” instead of “I,” and bring in pizza.
Sound Byte
Before you parachute in, have a plan to engage with people and issues. Remember that titles don’t matter, but driving collaboration and product success do.