Your First 2 Weeks with an Existing Product

October 12, 2017 / Paul Hurwitz

An important skill for a product manager is the ability to parachute into an existing product and land on your feet. What should you accomplish during your first 2 weeks?

Step 1: Set up meetings with your product’s key stakeholders

Step 2: Find (or Create) the backlog

Every meeting that you have with key stakeholders will reveal items that have been promised or already committed to. Are there any golf course deals? Did the CEO promise something to a client or prospect on the golf course? Every stakeholder meeting will include a few small requests for things that have already been committed. Write them down and put them into a backlog but don't make any commitments until you know the full scope of the request.

For each of these requests your response should be ‘that sounds like a reasonable new feature, let me get back to you after I’ve done some research.’

It’s not the Product Manager’s job to prioritize everything in the backlog. It is the product manager’s job to populate the backlog and facilitate the prioritization. The stakeholders will drive the prioritization. Sometimes a promise is made to a customer and it’s worth a lot of money and that will affect the prioritization, other times it’s who yells the loudest. But nobody should be prioritizing the backlog in a vacuum. In the Agile world, backlog grooming takes place often and in many organizations it’s not just the development team participating. You would have sales, playbook management, product marketing all participating and it’s a chance to make sure that everything in the backlog is prioritized correctly. There is also strategic prioritization that happens where the product strategy stakeholders meet to decide what the roadmap priorities look like for the next quarter or the next year or whatever time frame you work on. There will always be updates and resets based on reality but the prioritization needs to take place.

Learn to set expectations

When you are first putting together or organizing your backlog, executives, sales teams and other stakeholders will most likely anticipate a decade's worth of quasi-promises in the next quarter or release. One of the things you absolutely have to do is manage expectations. The #1 symptom of absentee Product Management is a haphazard backlog with dozens or hundreds of urgent items in there. You have to learn to set expectations and be able to say ‘that’s not realistic, let's talk about it’.

Let people know about risk as early as possible so that they can start to plan for something not happening.

Step 3: Schedule calls with customers

In your first and second week you need to schedule calls with customers. They don’t have to happen right away, but even if you don't get to talk with them immediately you want to be booking them. Start by pulling a list of representative users, don’t go with just the top three customers. When you call the customers ask for a 30 minute phone chat.  If you can get more great, but 30 minutes should suffice to get some valuable input from them. When booking the call tell them you’re the new product manager and want to learn more about your customers and their use of the product. It may take a couple of weeks for these calls to actually happen but get some requests out. Block the time on your calendar for them. Saying you are not in sales is important I think. If the customer doesn't feel they are going to be pressured to buy something they're more likely to be willing to speak with you and be honest in their opinions.

Step 4: Learn your product

Put very simply, you need to learn your product. What you do to learn your product will vary depending on what it is. If it's an online service create a playbook and carefully look at all the steps that are part of playbook creation. Are there any work flow issues? If it's a financial or playbooking application like I managed, load in some recent financial transactions and see what a typical user would be doing and what problems you might discover. For a developer oriented API or something similar, scan the code samples and the web services. Whatever your product happens to be, run it through its paces and see what issues you discover. Maybe even read the manual or documentation. So many times we tell users to just RTFM, well, do it.

While you are learning your product, write down a dozen things that you think you want to fix or change. See if those items are in the backlog you are creating. Other people might have discovered the same things.

You only have a few days to experience your product as a naive new user so use it wisely to really put your product through its paces before you've learned too much from other stakeholders or users. Sometimes when stakeholders are ‘in too deep’ with their product they don’t notice the low hanging fruit. These items can be quick wins as a new product manager which I’ll talk about more in part 3 of this series.

Step 5: Introduce yourself to your development team (gently)

"A great product manager has the brain of an engineer, the heart of a designer, and the speech of a diplomat.” Deep Nishar, former SVP, Products & User Experience at LinkedIn

Gaining the trust and respect of your development team is one of the most important things you can do. Building the group dynamic on trust and respect is crucial to having a good working relationship with your team. Concessions are inevitable in your discussions about what can be realistically delivered, as opposed to everything that's been promised. The first four steps help you start your dialogue with the development team with a solid understanding of stakeholder opinions, the product, what’s been promised and the problem your product is designed to solve.

How do you gain their trust?

Join some stand-ups, attend daily scrum or whatever other meetings regularly occur. Start by just listening and then after you’re a regular feature start talking to people afterwards. Grab lunch with random developers or designers if you can. Go to happy hour if people are going.

Be a mensch instead of an MBA

I attended a workshop hosted by Rich Mironov and something he said that stuck with me is the idea of being a mensch instead of an MBA. When working with anyone, especially developers, be nice to them. They've probably been yelled at a lot because of people who have over-promised unrealistic expectations. Be a nice guy to the developers and they’ll start to trust you and respect you. Lightly sell the value of product management to them since they probably have not had good previous experiences. If you are coming in as the first Product Manager in a company and the founder led product beforehand they could be used to a tyrant yelling and ordering them to do things. If you are in a company with an existing product infrastructure you don't know what the quality of product management has been so you may need to sell the dev team on the value of product management. If the development team thinks you're coming in to perpetuate what's already in place, which is often ‘over promise under deliver’ you won't gain their trust. If they think you're coming in to be their conduit to the rest of the company and instill some sanity to their work flow they'll respect you and be happy with you. You can push them to perform well but don't push them to deliver more than they can. You need to understand what their velocity is and how much they can realistically deliver for each release. Most importantly position yourself as their champion.

What shouldn’t you be focusing on in your first 2 weeks?

I’ve spoken about the steps you should take and what you should focus on during your first 2 weeks in your new role. What things should you deprioritize during this time?

There are probably many meetings that were scheduled by a predecessor or whomever was filling the role. I would say cancel all those meetings. You don’t know which are important and which ones aren’t. Tell people that once you’ve gotten acclimated in your new role you will reschedule meetings that are necessary. Anytime meetings are cancelled, people are happy and if you reschedule fewer of them you will garner good will among your co-workers. Also, just about anything not in my first 5 steps above is peripheral to what you should be doing right now. For example, a new product manager can’t do demos for sales presentations until they know their product really well. I would suggest not even joining these meetings as a listener until you’ve been in the company for at least a month.

Learn the product, the market, and the plans. Do this before engaging in operational and sales issues.