Parachuting into an Existing Product
•Transferir como PPTX, PDF•
1 gostou•321 visualizações
How to land on your feet as a product manager. I recently presented on this topic to give product managers a 5 item checklist of what to do when you join a company that has an existing product that you are taking over.
Recomendados
Recomendados
Mais conteúdo relacionado
Semelhante a Parachuting into an Existing Product
Semelhante a Parachuting into an Existing Product (20)
Último
Último (15)
Parachuting into an Existing Product
- 1. 11 Howtolandonyourfeetasaproductmanager March 30,2016 Paul Hurwitz Health Tech Product Director Parachuting into an Existing Product
- 2. 2 About Paul Hurwitz • 15+ Years in technology roles • 10 Years in Product roles • Finance/Accounting, Life Sciences & Health Tech products • Have parachuted 3 times into existing products.
- 3. 3 About Paul Hurwitz • Have parachuted 3 times into existing products. – Centage Corporation (Financial/Accounting) – Medidata Solutions (Life Sciences/Pharma) – ActiveHealth Management (Population Health Management)
- 4. 4 In the first 2 weeks – 5 Steps • First impressions are very important • Difficult to recover from a bad first impression • Learn how product managers are perceived
- 5. 5 1) Meet with Key Stakeholders • Window into short-term urgency for your product • Find out what the real priorities are
- 6. 6 BusinessStakeholders • CEO (depends on size of company) • Marketing director • Adjacent product managers • Sales director • Account Management TechnicalStakeholders • VP Engineering / Development Lead • QA Lead • Customer Support Lead
- 7. 7 Discussions with Stakeholders What is the problem that we are trying to solve? • Face to Face (if possible) • Listen! Don’t talk too much. • Take notes
- 8. 8 2) Find (or Create) the backlog • What’s already been promised? • Any golf course deals? • Don’t make any commitments until you know the full scope
- 9. 9 3) Book Calls with Customers
- 10. 10 4) Learn Your Product •You only have a few days to experience your product as a naïve user
- 11. 11 5) Introduce yourself to the Development team (gently) •“Be a mensch instead of an MBA” – Rich Mironov •Position yourself as their champion
- 12. 12 First 30 - 60 Days – Another 5 steps
- 13. 13 1) At least 5-10 Calls with Customers •Write up summaries •here’s what I heard from customers
- 14. 14 2) Create a Product Strategy
- 15. 15 3) Get intimate with your financials
- 16. 16 4) Preparethe business for a roadmap reset •Set proper expectations •What really, truly has to be in the next release?
- 17. 17 5) Get a few quick wins
- 18. 18 Conclusion "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 for products and user experience at LinkedIn 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.
- 19. 19 Contact Info • paul@phurwitz.com • www.phurwitz.com • http://lnkdin.me/phurwitz • http://twitter.com/phurwitzma
Notas do Editor
- Centage: 3rd employee but product already existed. Took over tech support and eventually introduced product management into the company and stayed there for 12 years. Medidata: I parachuted in and took over product management for 1 of the companies 11 product families. ActiveHealth: the product I am developing now actually doesn’t exist, but the company has a numerous products and programs that do. As director of product for reporting, I have instituted product management for reports (which do exist) and am building a new platform for delivery of reports (which does not exist).
- It’s important to understand how others perceive product managers. In a company with an existing product management infrastructure it is much easier. Hopefully it is a good infrastructure and people have had good relationships with PMs. In growing startups, it can be much harder. Especially in companies where the founder(s) still have a strong influence. In that kind of a situation product managers are often hired to have a more execution focused role, execute on the founders ideas. It could take a lot of effort to convince the founder to give up the product reigns enough to allow a true product management lifecycle to take root and become truly customer and stakeholder focused. In either case, the ideas I’m going to share today will help you parachute into an existing company with an existing product and get a good understanding of the company, it’s product(s) and it’s customers.
- Starting with the influential stakeholders (both internal and external) will give you a window into the short-term urgency for your position or new product assignment. Dilbert Jack story. Every stakeholder thinks that their ideas or features are the ‘top priority’ but your goal is to find out what the real priorities are. Tell story of Centage, This Dilbert became unnecessary after I became product manager because we started listening to stakeholders. Listening to stakeholders and customers is everything. This Dilbert is my favorite one and I used to have it taped up in my cubicle. When the founder of my old company up in the Boston area would come to me with something to do or an idea for our product, I would point to the cartoon and then we’d have a real discussion about what was really important. The thing to remember is that every stakeholder you speak to thinks that their ideas or features are the ‘top priority’ but your goal is to find out what the real priorities are. I’m going to digress here for a moment to talk about my time at my first product role because I think it’s relevant to this point in my presentation. When I started there we were very much in startup mode and everything we did came from the founder. I started doing Tech Support, then I created a training and consulting team. After being at the company for 4 years, I moved over to the dev team doing a bunch of things: writing requirements, top level tech support, doing product demos, doing QA, release engineering and DevOps, basically everything but writing code. This role turned into being a technical product manager. The company hit a slump, we weren’t growing. We were still very much in founder’s mode. I realized we needed to make a change and start listening to our customers more. Anecdotally I knew the features we needed to help us grow. These top features being requested in reality were exactly the features the founder said “we don’t need, our customers’ won’t use those features.” I took that as a challenge to learn product management and show the owner of the company why we needed them. I spent several months conducting surveys and talking with our most active customers. The data I collected showed us the top 10 features we needed to be competitive and some of those were the exact same features the founder said we didn’t need. I showed him the data and convinced him he was wrong. Faced with the facts I had I was able to tell him what our customers were saying, it wasn’t just my opinion anymore. I made the case we needed a product manager and he agreed and I become the product manager. This Dilbert became unnecessary after I became product manager because we started listening to internal and external customers. And that is key to good product management Listening to stakeholders and customers is everything.
- This list of stakeholders is not exhaustive some surprise stakeholders. Like co-founder, developer whose been there 10 years Quickly figure out who they are No magical number This list of stakeholders is not exhaustive and it’s important to keep in mind that there will be some surprise stakeholders. People you didn’t know were important stakeholders or even existed. But they can be important. People like co-founders that might not be in your direct chain. Or the individual contributor developer who is still with the company 10 years later. You need to quickly figure out who these people are and include them in your first stakeholder conversations. There is no magical number to how many people you should be talking to. You need to identify all of the critical stakeholders as quickly as you can and speak to as many of them as possible.
- A lot of what you hear will be opinion but it helps you start forming your own opinions and establishing facts What’s Working? What’s Not? Why are those things not working? What could be done better? Who are the stars? what is the problem that we are trying to solve? Fire Hose! Take notes It will also let people know that you aren’t trying to come in and take over things based on your own ideas only, rather that you are trying to understand everyone’s concerns and ideas and establish facts before you act. Key Questions: A lot of what you hear will be opinion but it helps you start forming your own opinions and establishing facts What’s Working? What’s Not? Why are those things not working? What could be done better? Who are the stars? In addition to finding out the dynamics in the company and who plays nicely together in the sandbox, what is also important to find out in these chats with stakeholders is “what is the problem that we are trying to solve?” If you are not solving a problem, then you aren’t doing a good job as a product manager. You are going to learn a lot about the company and your product during these conversations. It will be like drinking from a fire hose and you will be digesting a lot. That’s why it’s important to take notes. I’ve found myself having these conversations, taking notes and then going back to these stakeholders I spoke with during my first week in the company and talking with them again once I have a better understanding and get more useful information. By having meaningful discussions with the stakeholders they will understand that you are interested in learning as much as you can as quickly as possible. They will, hopefully, respect that you are trying to understand the situation on the ground and will move forward working based on as broad an understanding of opinion and fact as possible. It will also let people know that you aren’t trying to come in and take over things based on your own ideas only, rather that you are trying to understand everyone’s concerns and ideas and establish facts before you act.
- Every meeting you have with stakeholders will reveal things that have been promised or already committed to. Any Golf course commitments? (did the CEO promise something to a client or prospect on the golf course?) don’t make commitments until you know the scope of the problem The #1 symptom of absentee product management is a haphazard backlog with dozens (hundreds) of urgent items. It’s not the product managers job to prioritize everything in the backlog, just to facilitate the prioritization. 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. It’s not the product managers job to prioritize everything in the backlog, just to facilitate the prioritization. The stakeholders will be the ones pushing the prioritization. Sometimes a big promise was made to a big customer and is worth a lot of money and that might have to lead the prioritization, but nobody should prioritizing the backlog in a vacuum.
- Book calls with customers, even if you don’t get to talk with them immediately. Pull a list of representative users – not just your top three customers I’m NOT in sales 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. Saying you are not in sales is important. If a customer doesn’t feel they are going to be pressured to buy something, they are likely going to be more willing to speak with you.
- If it’s an online service, create an account and carefully note any sign-up or workflow issues. If it’s an accounting application, load in some recent financial transactions. If it’s a developer-oriented API, scan the code samples. Whatever the product is, run it through its paces and see what you can find. 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.
- Gaining the trust and respect of the dev team is one of the most important things you can do. The 4 steps before this help you start the dialog with the development team with a solid understanding of the product’s stakeholders, the pain points and their solution and the product itself. If the development team thinks you are coming in to perpetuate what has probably going on, that is over-promise and under-deliver, you will not gain their trust. Position yourself as their champion. It will build the group dynamic on trust and respect - particularly during the inevitable concessions in discussing what can realistically be delivered. The 4 steps before this help you start the dialog with the development team with a solid understanding of the product’s stakeholders, the pain points and their solution and the product itself. Join some standups grab lunch with random devs or designers Rich Mironov said in a workshop I attended “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.”) If the development team thinks you are coming in to perpetuate what has probably going on, that is over-promise and under-deliver, you will not gain their trust. If they think you are coming in to be their conduit to the rest of the company and instill some sanity to their workflow, they will respect and be happy with you. Don’t push them to deliver more than they can. Understand their velocity and how much they can realistically deliver for each release. Position yourself as their champion.
- Write up summaries is your product solving the problem they bought it for? “here’s what I heard from customers …” instead of “here’s what I think.” People will notice that you’re working from primary information B2B vs B2C 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.” Phone calls or meetings with individual customers works in a B2B environment but may not work so well in a B2C company with thousands or millions of users. In either environment user surveys can be very useful. With tools like Survey Monkey and others, you can create surveys that will give you very useful information about what problems users are having with the product and why. Are they happy with their purchase? is your product solving the problem they bought it for? Useful additional features? UX problems.
- What is 90 Day Success for you as new product manager? No strategy means no focus. Are we targeting enterprise or small biz or individuals? Are we B2B or B2C? 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.
- Most products are intended to make money, and that’s how executives keep score. Know if your product is a star, a dog, or a zombie. A cash cow, a star, question mark or dog. Review your pricing, unit sales trends, and concentration of large deals. If a budget exists for your product or initiative, digest and know everything in it. 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. A cash cow, a star, question mark or dog. Whichever way you want to think about it, following the money is critical, and it’s often overlooked.
- Socialize some reduced expectations, and collaboratively work out a more achievable plan. I almost always discover that dates and commitments are far beyond what engineering can deliver. What really, truly has to be in the next release? Socialize some reduced expectations, and collaboratively work out a more achievable plan. What really, truly has to be in the next release?
- 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? What’s the low hanging fruit that you can direct the team towards resolving to get a quick win? Celebrate something with the team, using “we” instead of “I.” And bring in pizza.
- You need to have laser focus in these first few weeks and months in a new company What drives this list is the WHO, WHAT and WHY, and without that “why” a product manager is doomed to fail. That why is the problem the product is supposed to solve. Building new products and features is great, but unless you are Steve Jobs you need to solve a problem for the marketplace. This is especially true in B2B products and services (where I have spent my entire career). Companies won’t spend money on a new product or service unless it solves a problem they have. B2C is somewhat different where consumers will pay for something that is a ‘want’ and not necessarily a ‘need’ or solution to a problem. Steve Jobs again. You need to have laser focus in these first few weeks and months in a new company: it’s all about interactions with people and delivering value. What drives this list is the WHO, WHAT and WHY, and without that “why” a product manager is doomed to fail. That why is the problem the product is supposed to solve. As I said before you need to know what the problem is you are looking to solve. Building new products and features is great, but unless you are Steve Jobs you need to solve a problem for the marketplace. This is especially true in B2B products and services (where I have spent my entire career). Companies won’t spend money on a new product or service unless it solves a problem they have. B2C is somewhat different where consumers will pay for something that is a ‘want’ and not necessarily a ‘need’ or solution to a problem. Steve Jobs again.
- 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. I’m really much more into biking than parachuting, which I’ve never actually done.