My response to this question on Quora got some buzz so I thought I’d elaborate on it here. Far be it from me to ignore market demand.
1. Understand “why” first:
Do not prescribe before you diagnose. Remember that people are not stupid to have done as they have. They know more than you about the specific problems the organization has faced, have been working them longer and there are reasons why particular decisions were made. Your first goal should be “5 whys” on relevant issues before telling people “what” you think needs to be done.
Among my friends, we have a joke about ISO registration for people – granted based on whether you consistently do what you say you’re going to do. I firmly believe this is the functional basis of trust.
Kouzes agrees in Credibility, defining credibility in behaviour as doing what you say you will do. Credibility as a leader is then doing what we say we will do, since leaders represent the people they serve in common goals. Credibility is further defined by Kouzes as the product of values, competence, confidence, vision and honesty.
How is this relevant to starting a new product management position? You need to establish credibility with your new colleagues. Be clear on your values as a product manager / leader as this will guide your decisions and actions. What are the most important things you want the product to do for people?
Regarding competence, you may know what to do and how to do it from experience (you got the job didn’t you?), but an understanding of the current context is needed before anyone starts waving hands / chainsaws / megaphones around on vision and plans. You may be confident in your ability to solve problems, but that has to be applied to specific domain / subject matter expertise. And if you’re not honest about any of these initial gaps, no one will see you as credible.
As Josh Schwarzapel put well in the Quora thread, nothing will marginalize you faster than being bold and wrong early on. I tend to agree with the Eddie Obeng’s idea that if dealing with unknowns, you want to fail as fast as possible and iterate off that, but if dealing with known, failure is not acceptable. So better to listen first, figure out what works and what doesn’t, then pick the right next battle instead of coming in guns blazing. Any fool can regurgitate how things should be based on a cursory understanding of best practices. Experienced leaders know that ideas and words are cheap, knowing how to engineer meaningful changes in a professional manner is what they’re paid for.
2. Understand the complete business model, strategy and how current processes work.
Map out a one page canvas to take a big picture snapshot of the business model and strategy. Then find out how day to day processes work for that strategy, like release planning, customer feedback capture, development execution, sales and support.
Every data point could be a potential area of contribution as a product leader. Next level innovation in product management isn’t just on the product or features but the entire business model. Think about how you can own and engineer positive improvements across the board. Doing something different and valuable in each of these canvas areas yields creates competitive advantages beyond features that can be bought or copied. Some companies have done quite well for themselves doing something very innovative and valuable in just one major area of their business model while the rest is somewhat similar to other competitors.
Here’s Alex Osterwalder of the above linked canvas talking about this approach as well as John Mullins of Getting to Plan B getting at the same idea. Ash Maurya also applies this type of thinking in Running Lean, which I’ll be talking about in another post.
3. Become the market expert to development.
This is achieved by gaining outside-in experience actually talking to customers. Get out of the office as Steve Blank puts it so well. It is fairly easy to pitch meetings as a new product manager needing to understand customers, but just find a way no matter what – it’s the cornerstone contribution of the role. Understand the market problems you’re out to solve and how they can be solved otherwise. Be able to drop names and quotes on customer pain. Sit in silently on sales presentations to hear how market problems and messaging are being done. You can ask others for their views on value propositions and messaging to target markets, but don’t breathe internal fumes more than you test ideas against outside feedback and form your own thoughts – you’re supposed to be the expert.
4. Become the product expert to sales and marketing.
You should be able to demo within 15-30 days of starting and have made your own outward facing materials in the meantime – videos, presentations, elevator pitches, etc. Given the market data collection above, you should be able to explain better than anyone else why people throw money at your product. Be the go-to person who can answer tough product questions in presentations that stump others. Go through both the existing product backlog and bug list to understand each item. Rewrite stories / requirements to a consistent standard (e.g. based on personas and themes) as an activity if it helps. Set up lunch and learns with the product team and respective functional subject matter experts. Sit in on support calls to understand customer problems. Use the product and read the documentation, trying to solve the same problems as customers. It’s not rocket surgery – become an expert on the “product” part of product manager.
5. Develop a 30-60-90 day plan for what you need to deliver with your boss and other key stakeholders.
Senior management, heads of the different functional areas, development teams, sales and partner channels – your job is to serve these different stakeholders for the product you lead. Define the hypotheses you want to test and how success will be measured then the experiments and activities to get there. Some areas to consider:
- Customer Lifecycle / Sales Pipeline: Acquisition-Activation-Retention-Revenue conversion for web products, Funnel analysis for enterprise deals, Win / Loss Analysis for either
- Development: User Stories / specific features to be built, quantitative and qualitative acceptance criteria for quality assurance, reviews against requirements, team performance (although this is more development management, you know product management is doing their job if there is less thrash and uncertainty in the team)
- Release Management: Roadmaps, release ship dates and milestones within releases. Some agile shops don’t believe in roadmaps but every place needs a prioritized plan for what’s next.
- New Product Introduction: Interviews to test risks in all canvas areas (e.g. problem-solution) Minimum Viable Product and Reference Customers
- Existing Product Improvement: Quantitative profitability and A/B cohort analyses, support tickets / bugs, feature overhauls, performance benchmarks like load/process times
- Customer Satisfaction: Net Promoter Score, usage frequency / depth / breadth assessments like Customer Happiness Index
- Direct Customer Use: reports, dashboards and analytics for customers on their data
6. Establish critical relationships with representatives from the relevant functional areas.
You should know who to ask on particular subjects as well as be seen as the go-to / directly responsible individual for the products(s) you’re leading. I agree with Marissa Meyer’s statement that as a product manager you don’t have all the answers, but you work with others find them. Become a broker in answers and lead cross-functional problem solving. As a product leader, answers and solutions ultimately come from people and the relationships you have with them.