My Product Management toolkit (12): My 90 Day Plan as a Product Person

Soon I’ll be starting a new role as a Head of Product at a great FinTech business in London. I’m very excited about the role. There’s a lot of opportunity to make an impact and influence change. But where do I start? How do I prioritise change? These questions prompted me to start thinking about my 90 day plan for this role, identifying key steps and outcomes to concentrate on. I feel that the ‘3Ps’- people, product and process – are the most logical place for me to start from:


Objective 1: To assess current performance and ambitions of the people in the team and across the business; identify how I can help create the perfect conditions for them to do their day jobs and grow.

Key results:

  1. Individual audit and objectives-key results (‘OKRs’) – To understand strengths, weaknesses and development areas for each team member and have translated these into clearly defined goals and a personal development plan.
  2. Create a simple OKR measurement framework for team members (1) – I’m sure my new company will have a formal review framework, but I want to make sure that their specific quarterly objectives are measurable and are reviewed on ongoing basis beyond formal reviews once or twice a year. The goal is to make sure that personal OKRs are fully aligned with critical business goals.
  3. Create a simple OKR measurement framework for team members (2) – Even though OKRs aren’t necessarily meant to be a performance review tool, these will be very helpful in measuring and discussing personal progress. We can then make sure that individual OKRs align with overarching business and team objectives. I’ll have to make sure their objectives are highly measurable and feel somewhat uncomfortable, similar to the OKRs that I will set to measure my own performance (see example in Fig. 1 below).
  4. Hold at least 6 individual 1:1s with each of my team members within my first 90 days – Set a frequency and a clear agenda for regular 1:1s with my team members. I can imagine that different team members will have different preferences in terms of the frequency and content of our regular 1:1 sessions. I’ll agree this with my team members on an individual basis. I can imagine that our regular 1:1 sessions will cover a mix of OKR progress review as well any questions or issues related to day-to-day stuff.
  5. Establish and communicate team OKRs for the following quarter within my first 90 days – Agree with the team on max. 5 OKRs for the entire team for the following quarter. Share these OKRs – along with a related roadmap for the quarter – with the entire business by the end of my 90 day period at the latest.

Objective 2: To establish a product discipline within the wider technology function and communicate our role to the entire business within my first 90 days.

Key results:

  1. How does Product work with Technology, Design and Business Owners and why? – Agree with other ‘Heads Of’ and their respective teams on how to best integrate Product as a function, making sure the overall team structure reflects this. This agreement should be reached within 1 month from my starting, so that people have clarity about their roles and responsibilities.
  2. Communicate the role of product management, OKRs and team structure within my first 90 days – The goal is to make sure that everyone within the organisation know what the product team does and why. On a practical level, I want to make sure that people who sit outside of the product and tech team know who to turn to, when and why. I’ll be looking at the best way to (1) embed product managers within multi-disciplinary teams and (2) make these teams customer experience centric instead of just feature centric (see Peter Merholz’ great approach in Fig. 2 below).
  3. Talk to 100 people across the business in my first 90 days – The idea here is not to just have nice introductory chats across the business, but use these introductions to really learn about the direction of the company, views on products and customers. I might even ask the same questions in each conversation, almost like a mini research project to identify common themes (see Fig. 3 below). I will thus create a much better picture of key problems and opportunities to consider, which I can then feedback to senior management along with my related recommendations.
  4. Learn from at least 3 other product teams in my first 90 days – It will be good to learn from other product teams in different industries to compare notes on best practices, understand what worked well and what didn’t (and why).
  5. Shadow at least 10 different teams for at least 1 day in my first 90 days – In my experience, there’s hardly a better way to learn about a business, its products, stakeholders and challenges, than sitting with the different business teams. You can actively shadow your colleagues as they talk to customers for example (sitting with customer support is always a good one!). Equally, I’ve found that just sitting with a team on a regular and overhearing their conversations can give you valuable insights into to their worlds and their day-to-day challenges. This is something I strive to do on a continuous basis, well beyond my first 90 days, to make sure that I don’t develop tunnel vision.


Objective 3: To understand the current product portfolio and its fit with the needs of (target) users and against the market(s) the company is operating in.

Key results:

  1. Overarching business and product vision – What is the long-term vision for the business and why? How does this vision translate into a product vision? Is this vision well understood and shared across the business? I will work with the rest of the product team to work out how we can best drive this vision on a day-to-day basis and flesh it out so that it becomes a key driver for our products.
  2. Business strategy and business goals – Understanding the long and short business strategy is critical. Having an overarching vision is great, but it’s important to have context on how we’re looking to deliver on this vision. Which markets are we looking to target and why? Which customer segments are driving our vision and why? As a product person you might be closely involved in shaping the answers to these questions, but make sure you find out if you haven’t!
  3. Understand user, business, financial and market data – When looking at data, I’m planning on splitting my time spent on data in three different areas. Firstly, going through the company’s financials and forecasts to form a better picture of growth, profit margins and customer segments. I will then use this understanding to link back to the overall business goals – see above – and business strategy. Secondly, understanding our user segments, demographics and behavioural patterns will help me to better frame the problems or unmet needs to address. Thirdly, what does the overall market look like and how does it break down into specific customer segments? Who are our main competitors and what are their differentiators?
  4. Do a quick product (portfolio) audit – It will be interesting to really understand the value of the current value proposition and product portfolio. What problems do these products solve and for whom? Are there any customer needs or problems currently not solved by our products or services? If so, how do our (target) customers solve their problems or jobs without specific products or services in place?
  5. Talk to customers and partners – My goal is to speak to a good number of customers (B2C and B2BC) and partners in my first 90 days and beyond. This means developing good relationships with our sales and accounts people, who can help arrange short, problem interviews with customers. It will be my first foray into getting some real world feedback from our customers on, for example, how they currently use our products and why. I can then work out how to best engage with and learn from our (target) customers on an ongoing basis.
  6. Create a simple KANO model – I want to map our current products in a KANO model, identifying ‘hygiene factors’ and ‘delighters’ in order to get a better understanding of the competitive landscape (see Fig. 4 below).
  7. Explore competitive products and services, ‘mystery shopping’ – In my experience, mystery shopping is a good way to understand the competitive landscape and the differentiators of your own product or service. Using competitor products or observing customers using competitive products is a great way to learn more about user needs and your own product. How does your product or service compare to the competition? How does it benchmark?
  8. Study customer demographic and usage data, identify trends and patterns – I’ll definitely try to get my hands on whatever customer data I can get in order to learn more about customer segments and their behaviours. This will help me to understand trends and opportunities, identifying where we need to focus our product efforts and why.
  9. Identify which markets to target and why – Combining data on our products, our (target) customers and market needs to identify the best market(s) to target. This should also tie in nicely with the relevant strategic themes for the company, for example ‘internationalisation’, ‘partnerships’ and ‘retail’ and related business objectives.
  10. Use quantitative and qualitative data to create an experience map – Who are our users? Which jobs do they need to do and why? How do they feel about our products and services in relation to their jobs-to-be-done? Creating an experience map will help in understanding user behaviour in relation to our products and services. I’ve found the experience map exercise to be particularly helpful in relation to companies that don’t have a unified, shared view of their products or customers.
  11. Translate into a product strategy – Your initial product strategy can be fairly high level and you don’t have to lock yourself up in a dark room for 6 months to draft a plan. I believe it’s important to take your learnings and convert them into a plan which outlines how we can achieve critical business and customer goals, without getting too immersed in the detail. Instead, I tend to look at the high level milestones or building blocks that need to be in place to achieve specific business goals or solve customer problems. Melissa Perri recently wrote a really helpful article about how to create a product strategy, which I’ll definitely include in my toolkit (see Fig. 5 below).


Objective 4: To introduce the ‘minimum viable process’ necessary to address specific organisational or product related problems which impact product development or our bottom line.

Key results: 

  1. Is there a roadmap? Do we need one? – I know that some companies deliberately don’t have product roadmaps. Instead, they fully empower their product managers and engineers to liaise directly with customers and deliver against high-level strategic themes – companies like Hubspot are good examples in this respect. I, however, find having a product roadmap a very important tool in creating a product and customer centric culture across the entire business. A roadmap can be an incredibly helpful tool in conveying high level goals, milestones or themes to business stakeholders, teams and customers. I always make it clear that a product roadmap isn’t set in stone, but that it will give everyone in the business important context on what we’re looking to achieve and why.
  2. How do things get prioritised? – What criteria does the company use to add and prioritise things onto the roadmap. Are a product vision and roadmap in place that drive the roadmap? How do people assess new product opportunities? One the first things I’d like to do is to understand about any product or project milestones in flight or planned, and their underlying rationale.
  3. Product backlog, the next level down from the roadmap – Does the company have one product backlog or do the different teams have a number of backlogs that they work against? If so, what does the backlog look like, has it been ‘groomed’ and prioritised?
  4. How do things get shared across the business? (1) – Understand how people across the business know what’s going on from a product development and performance perspective. Often I see companies where product development is perceived to be a ‘black box’, with people being unclear about what gets developed (and why). I’ve also come across companies with a project management office that sends out status reports which are very task based and don’t necessarily provide a good update on the value we’re looking to create for customers or on tangible product progress. Like I mentioned in point 1. above, my preference is to have a high level product roadmap which is shared across the entire company (and ideally with customers as well). This acts as a simple but very effective example to convey why we’re building certain solutions or features and how we’re progressing against specific milestones or goals (see example in Fig. 6 below).
  5. How do things get shared across the business? (2) – Product review meetings, ‘all hands’ sessions or product retrospectives can also be a very effective in engaging with people across the business. The main reason why I’m always in favour of live demos over status reports is that people typically find it easier to see working software or a prototype instead of a written document. Even if you’re showing a non-finished article, you’ll at least be able to explain in person that a product or feature is still work in progress and what it is that you’re looking to learn (and why).

Fig. 1 – Sample OKRs to measure and review individual performance:

Instead of:

“To launch a new mobile app”

We will make the result more objective and measurable:

“To launch a mobile app for iOS and Android by the end of September ’16 and to achieve a 2% increase in mobile conversion by the end of November ’16.”

And make sure it’s aligned with key business objectives:

“To increase repeat purchase from 1.7 to 2.5 by 31 December ’16.”

Fig. 2 – Product managers embedded within multi-disciplinary product teams

Image Credit: Intercom

Taken from:

Image Credit: Peter Merholz

Fig. 3 – Sample questions to ask during my first my introductory conversations in my first 90 days:

Generic questions to ask:

  • What is the overall vision of the company?
  • What are the key company goals or success criteria? What does success look like and why? Which one(s) are you working towards (how and why)?
  • How would you describe the company culture – what do you enjoy about working here, what could be improved?
  • Are you involved in developing new products or services? If so, how? If not, why not?
  • Who is your main customer? Is your customer internal or external? What do they care about and why?
  • What do you see as the main differentiator(s) of the business? Where do you see opportunities for the company or where are we lagging behind?
  • What are your observations with regard to the new products we launch to market and existing products that are already out there?
  • How do you currently collaborate with other disciplines within the company to deliver against company goals (e.g. working with traders, customer support or developers)

Questions about continuous improvement:

  • What does continuous improvement mean for our business and why?
  • Why is continuous improvement so important and what does success look like?
  • Have you got an example of where continuous improvement materially impacted the business’ bottom line? If so, how?
  • What kind of processes have you put in place to ensure continuous learning and improvement?
  • How do you go about instilling and maintaining a continuous improvement mindset across the wider business?

Questions about technology teams and leadership:

  • How do the developers currently interact with product managers, QA, UX as part of product development?
  • What is working well in that collaboration and what can be improved? Why?
  • What are the key roadmap goals or milestones for the coming quarter? How is success being measured?
  • What does the definition of “DONE” look like for the development team?
  • How and when do developers get involved in the planning process?
  • How do you currently structure your development team? For example, is it based on internal vs external, customer segments, specific problems, features or metrics?
  • (how) Do developers interact with customers?
  • Do you run a “dual track scrum” approach? If so, who gets involved in product and technical discovery?
  • How do you manage or mitigate technical risk?
  • What approach do you use with respect to testing? For example, do developers use TDD to test their code?
  • How do you balance fixing bugs, addressing technical debt with delivering business value, releasing new features?
  • How iteratively do the cross-discipline teams work? Is there a culture of continuous deployment?

Questions about customer experience and marketing:

  • How does marketing collaborate with product managers? When and how do marketeers get involved in the product lifecycle?
  • Who is responsible for developing a go-to market strategy? Who develops marketing strategies and related collateral?
  • Which customer profiles, segments and demographics are at the heart of our business strategy and why?
  • How do we go about reaching out to our target audience? Are there are specific areas that you are looking to optimise?
  • What does market growth look like and why? Are we looking at new – opposite or adjacent – markets?
  • What happens at the ‘initial insight’, ‘plan’ and ‘execute’ stages and why? It would be good to understand specific activities (e.g. story mapping, ‘jobs’, experience mapping, empathy mapping, etc.)

Fig. 4 – Create a simple KANO model

Image Credit: Wikipedia

Fig. 5 – Product Strategy Canvas

Image Credit: Melissa Perri

Fig. 6 – Sample high level product roadmap

Roadmap: Roman Pichler

Related links for further learning:


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: