Author Archive

“85% of job success comes from well-developed people skills.”

“70% of team issues are caused by people skills deficiencies.”

It’s becoming increasingly more common for Product Management and therefore product managers – who are generalists – to sit at the centre of the business surrounded by specialists, making collaboration with everyone in your team and stakeholders across the business a fundamental part of the job in order to manage the product and product business effectively. How you handle these relationships will contribute significantly to the success of the product and your role as a product manager.

Human Powered by Trenton Moss will give you a better understanding of yourself, increase your empathy to help forge better relationships and provide you with the tools you need to inspire those around you, setting you and your product up for success.

Throughout the book, there are short realistic stories with characters as examples to explain situations and resolutions making them easy to digest and relate to.

They don’t teach you how to handle conflict at school, but Trenton does a great job of setting out a framework to help you resolve conflict. The book covers 5 other key areas, with a framework for each including:

1. Conflict resolution
2. Strong relationships
3. Leading and influencing
4. Facilitation
5. Storytelling
6. Outbound comms

For me, the first three areas made the most impact, and I can definitely see the frameworks and advice useful for the final three chapters for those needing tips on ways of improving in those areas.

I’d recommend this book for all product directors and product managers/owners.

EQ is the new IQ!

You can order the book here: https://www.amazon.co.uk/dp/1781336067/ref=cm_sw_r_apan_glt_fabc_4ZFMT00SGSVD473E0K56

This is the best book I’ve read on DevOps and it follows on nicely from Gene Kim’s other book The Phoenix Project.

It’s quite easy to think that DevOps practices are just something that dev teams deal with and the value is simply just an increase in throughput, but the book provides clarity on the colossal value that adopting a DevOps culture and the principles can have on teams, the business, and customers.

Throughout the book, Gene echoes the importance of having the whole product team (product manager, designer and several engineers)) involved in the transformation, as well as focusing on outcomes, and to achieve outcomes you need to collect data and learn through experimentation which is covered in the book too.

Gene gives good advice that it’s important to avoid funding projects and instead you should fund services and products: “A way to enable high-performing outcomes is to create stable service teams with ongoing funding to execute their own strategy and road map of initiatives”.

This is the most comprehensive and practical DevOps guide out there and the layout makes the content easy to digest. The book covers:

– History leading up to DevOps, and Lean thinking
– Agile, and continuous delivery
– Value streams
– How to design your organisation and architecture
– Integrating security, change management, and compliance

The principles and tech practices of:
1. Flow
2. Feedback
3. Continual Learning and Experimentation

“Our goal is to enable market-oriented outcomes where many small teams can quickly and independently deliver value to the customer”

Previously ‘Product Management’ as a function has been part of the tech or marketing department and it’s still a relatively new concept to have Product Management as a separate department in an organisation.

As a result, there are many common misconceptions that the main function of Product Management and the Product Manager/Owner is to define features themselves and work with tech to deliver them, making it somewhat frustrating when marketing, insights, commercial team or any other department outside of product make a request which takes up tech effort which could have otherwise been spent on pushing your own changes.

So if this is a misconception, what is the role of Product Management in the wider organisation?

Product Management as a function/department sits in the middle of the organisation where the Product Manager is a generalist who collaborates with the specialists across the business to help manage the product business and develop the product, which includes working with:

  • Technology / DevOps and Designers/UX to learn through experimentation and reach outcomes early and often by developing the product continuously
  • Marketing to grow the product
  • Customer support to help them provide an A* customer service
  • Legal / compliance team to ensure the product is compliant
  • PMO / Project Managers to support them on cross-cutting high-value initiatives
  • Commercial / Bus Dev to take advantage of opportunities
  • Data / Insights team to gain access to qual/quant data, learn and understand how you can use data better to deliver more effective outcomes
  • The C-suite especially CEO to understand the business goals and ensure your product goals aligns with them
  • Yourself, the market and customers to analyse qual/quant data to find out what problems there could be to solve

As a Product Manager, you may feel overwhelmed by a sudden bombardment of requests coming from certain departments all of a sudden for example marketing requests, and a positive way of looking at this is that these inputs are essentially all just product ideas and part of qual/quant data analysis to help improve the product/product business which as a Product Manager you need to manage.

You may also find that you are spending the majority of tech resources on marketing requests for months, which is absolutely fine, if this is the highest priority work – the importance of growing the product business should not be underestimated.

With lots of valuable input incoming at a frequent rate, as a Product Manager, it means that you need to be organised, proactive and utilise your emotional intelligence to ensure you get the most out of everyone and that you handle situations rationally. What will help you is:

  • Accepting and believing that you are one team working together to improve the product/product business
  • Having a tidy data-driven prioritised product backlog which anyone can access
    • This will make it easier to say why someone can’t have what they want now!
  • Presenting your product roadmap, successes and what’s up next to key stakeholders on a regular heartbeat, but also ensuring that stakeholders have access to real-time updates of the product roadmap. Aha.io is a great tool for this
  • Know your customers, market, product strategy, backlog and data, so you can be assertive and lean into tense situations – Managing Product = Managing Tension is a great book to help give you confidence to lean into tension

A Product Manager is accountable for the success of their product and therefore also needs to manage the product business, not just develop a product.

Steven Haines is a globally recognised expert in Product Management who has done incredible work professionalising Product Management. I’d recommend reading the below books of his:

As Haines says “The system of product management touches and influences all the organic supporting structures-all the business functions. Think of the human body; product management is in the circulatory system, the neural network, and, of course, the command and control center (the brain).”

A PRD (Product Requirement Document) helps a product manager write a story on how to get from problem -> solution methodically. Often problems can be so big, complex and have ambiguity that it’s hard to know where to start, so a PRD will help you rationally approach the problem and get the support you need to reach an efficient and effective outcome.

It’s important to point out that it’s not necessary to:

  1. Use a PRD for every single problem/idea, normally only for epics/initiatives/features/medium or large-sized items.
  2. Complete the whole document, only fill out bits you need, you may find that you only complete the problem/value and hypothesis parts.
  3. Work on it in a silo. You will achieve a more efficient and effective outcome if you get the rest of the product team (designer and engineers) and stakeholders involved at the beginning in a workshop format so that you can work as one team across the discovery phase.

A good place to create a PRD is in Confluence, so it’s easily accessible across the business allowing colleagues to easily comment remotely. I’ve also used Google Docs previously and copied some of the information into the epic of JIRAs to reinforce the problem we are looking to solve/projected value we are looking to get after to the development team.

The first few PRDs you write you might find it quite slow whilst you work out how to get hold of the qual/quant data, but you soon pick up speed as you become familiar with the key elements of discovery and have the data already accessible at your fingertips.

It would also be helpful for new starters if you add a completed example of a PRD to the top of the PRD template which will help add some context for them. Some PRDs can be quite lengthy if the problem is big, complex and has a lot of ambiguity, so it’s worth adding a table of contents at the top making it easy to navigate through the document.


Including a list of people who are involved:

RoleContact
Product Manager. <tag person/<name>
UX/Design<tag person/<name>
Technical<tag people/<names>
Stakeholders<tag people/<names>
Jira/Design/Helpful Links <tag person/<name>

Problem/Value/Idea

A description of the problem or idea along with projected value if you have this. This is a good chance to spend quality time digging into the problem to build up a business case using qual/quant data.

  • Idea: Supporting Dark Mode in our apps…
  • Problem: Our iOS app is currently a 3* rating and Android app 2*, with the top problems being…
  • Problem: 70% of our customer support queries relate to promotions which cost us £x / month
  • Problem: Our day 1 churn rate is higher than we expect…
  • Problem: We currently release new software iterations monthly, rather than daily…
  • Problem: In the latest customer survey, 10% of respondents report the product being slow and unstable…
  • Problem: 20% of customers don’t feel rewarded for their loyalty
  • Problem: Our total marketing communication engagements have gone down since complying with the new GDPR regulations, making it harder to talk to customers frequently
  • Projected Value: Saving customer support costs by £
  • Projected Value: App rating > 4* resulting in healthier ASO and raking and therefore an increase in organic installs creating 20 new customers a day
  • Projected Value: Day 1 churn rate under 20% resulting in £xx revenue increase
  • Projected Value: New customer conversion rate > 30% resulting in £xx revenue increase

Hypothesis

List out one or more hypotheses you come up with to test out. This is a great opportunity to collaborate with the whole product team (designer and engineers) and stakeholders, not only to compile the list of experiments but also what data you need to learn and what tools you might need to execute the experiments.

  • Providing existing customers with the ability to refer their friends will increase new customers incremental by 10% worth an extra £xx revenue increase
  • Having a stepped registration form will increase the registration rate by 10%
  • Solving all customer queries in the app store and responding to every app store review within 3 hours will increase customer satisfaction and therefore our app store rating, which will in turn help ASO and our app store ranking

KPIs

  • Volume of engagements with feature x
  • Conversation rate
  • ARPU
  • CPA
  • Retention rate
  • Day 1 churn rate
  • LTV
  • Registration rate
  • Crash levels
  • Deposit elapsed time
  • Session time
  • Login elapsed time

Market Analysis

If you have competitors who have solved the problem already, this is a good place to document the UX. Also, detail your target personas and other details about the market which will give you a better idea of who the product iteration is for.


Customer Research / Validation

Detail any qual/quant data you have gathered relating to the problem/idea eg. customer interviews, financial/engagement data, trends, and any historical experiment results which are relevant.


Constraints

  • Regulatory live date of x
  • Marketing tv campaigns going live x
  • Low front-end development capacity
  • Utilising platform/tool x
  • Time to market
  • Dependencies on teams x

High-Level Requirements / Use Cases

This shouldn’t be at user story level (detailed spec), but instead, just an idea of customer flows/use cases and considerations covering:

  • Functional
  • Non-functional (since the rise of DevOps, this gets covered as BAU/as part of development in most cases)
  • Customer support
  • Marketing
  • Tracking

Flow

Embed a mock-up, flow, UX or prototype.


Risks

  • Lots of ambiguity, so it could take a while to reach the desired outcome
  • Other higher priority work could mean that we don’t have the tech capacity to get the solution to market in time to reach the optimal outcome
  • The problem may not be such a big problem when we go to market
  • We may only solve part of the problem because of x
  • It could take more than 3 months before we learn because of x

Technical Considerations

  • We have plans to replace the existing platform in the next 12 months.
  • We need to conduct an RFP on tooling
  • This is the first time we are conducting experiments, so we need to considering process and tooling

Go-to-market Strategy

This is where you can detail the elements you need to consider/action to have a successful go-live covering:

  • What product support marketing require to market the product iteration effectively
    • Special promotions
    • Signposting across the product
    • Training, user guides
  • Customer support training
  • Release preparation to coordinate with any time-sensitive fixed timeframe marketing campaign especially TV ads
    • Day 1 plan
    • Feature switch process
  • Regulatory approval
  • Production access for end-users

Q&A

Adding a question and answers section at the bottom allowing you to add notes from meetings and tag anyone responsible for answering the question.

QuestionsAnswers

Excited to have received an early copy of Human Powered by Trenton Moss.

Psychology and Product Management are my favourite subjects, so I’m really looking forward to reading this book which combines them both.

Product managers are generalists and require support across the business from specialists in every area making EI skills important to have when working in Product Management. Demand for high EI skills will grow significantly over the next decade, especially as it becomes even more common for businesses to put Product Management at the heart of their organisation, so it’s great to see books like this addressing the skills gap.

Review of the book to follow over the next 2-3 weeks!

More info on the book: https://www.amazon.co.uk/dp/1781336067/ref=cm_sw_r_apan_glt_fabc_E7C7NMM41NDZDYYX3FCG

Rewiring your brain to avoid your mind crippling your energy as it obsesses about past or future events is difficult, but it is absolutely possible, and this book makes it much easier.

It gives you tools on how to do it written in an easy to understand question-and-answer format to show you how you can silence these thoughts and use that energy more practically.

Essentially once you’ve made the journey into the Now, you will no longer have problems (only situations) as nothing exists outside of the Now. It is here you will find joy, are able to embrace your true self, and feel comfortable in the present.

“The energy form that lies behind hostility and attack finds the presence of love absolutely intolerable”.

Over 7 million people have read this book, it’s a best seller on Amazon, and I can understand why.

Loved reading this book by Eliyahu Goldratt as it’s written as a novel in a fast-paced thriller style, so once you start reading it it’s hard to put down.

Although it tells a heroic story of a manufacturing plant being saved from closure, the improvements closely resemble modern software development techniques – especially Kanban, as it touches on managing constraints, throughput optimisation, continuous improvement, less (smaller batch sizes) but more frequent, prioritisation, waste, the right KPIs (Goal), capacity, effort, WIP, value, estimation, and teamwork.

Throughout the book, rather than the external consultant (Jonah) just telling the plant manager (Alex) how to solve all of the problems they were facing at each stage of their continuous improvement journey to save the plant, Jonah coached Alex by asking him questions instead and getting him to find the answers out for himself, which sets Alex up for success in the future…reminded me of The Coaching Habit by Michael Bungay Stainer.

If you liked The Phoenix Project by Gene Kim you’ll love this book as it’s written in a similar style, and comes with all of the drama of balancing family life with a high demanding job.

In this book, Frank Barrett writes remarkable stories on leadership, learning, and innovation from a range of industry settings-from Jazz performance to automotive manufacturing.

Saying ‘Yes to the Mess’ ultimately means accepting as a management team that you don’t have control over how the teams on the front line get to the end goal or get a detailed plan on how they’re going to get there, and Instead, you can see how the team navigate through the uncertainty by learning along the way, being curious, creative, innovative, driven to succeed no matter how many experiments fail, and having fun along the way…aka improvisation.

Whilst there is no mention of product management in the book, there are clear lessons that can be learnt from jazz, which are also covered in other Lean product development books on how to handle uncertainty – by providing a vision and empowering the team to decide how they are going to get there, which as a result yields creativity, ownership, autonomy, learning, loyalty, speed, and value.

Jazz is a ‘risky business’ and the mindset of jazz would work in a multitude of environments with high uncertainty such as a product innovation hub, a new product that hasn’t been validated in the market, or a brand new feature for an existing product. Everything is an experiment to a jazz player, which reminds me of the hypothesis-driven product development approach.

After reading this book I definitely have a greater appreciation of jazz because of the level of risk and improvisation that takes place.

This wasn’t an easy read, but I enjoyed it, as it provided a unique angle on leadership from different perspectives.

If you’re an empowered Product Manager / Product Owner who has the authority to shape the strategy of your product and need insight into effective product strategy/roadmap practices and frameworks, this book by Roman Pichler is for you.

The book is well balanced giving you guidance on when and when not to use particular practices, for example when a product is yet to be validated in the market and therefore has not reached product-market fit, you shouldn’t spend your time making up a roadmap when you should be spending time experimenting and talking to target customers.

However when you’re scaling or have a mature product then product roadmaps would have many benefits which are explained well and are very accurate, such as collaboration, alignment and generally showing how you plan to progress towards your product vision.

I particularly liked The Strategy Canvas which looks like a great tool for competitor gap analysis.

The practices and frameworks are explained in enough detail that even if you’re not empowered to shape the strategy of your product, you could still find this book beneficial by understanding the tools and proactively having a stab at using them for your product.

Pichler leaves no stone unturned as he covers every aspect of product strategy from idea to execution, which ultimately enables product management functions to operate effectively.

After 17 years of researching leaders around the world, Jo Owen shares the secret sauce to what a successful mindset looks like at different leadership levels and how you can unleash it.

Seven mindsets that consistently came out of the research which the book focuses on:

1. High aspirations
2. Courage
3. Resilience
4. Positive
5. Accountable
6. Collaborative
7. Growth

This is the best book I’ve read on management and leadership as it compares the different mindsets you need across each leadership level, allowing you to build a crystal clear picture of what mindset you need to focus on to get to the next level of your leadership journey.

Owen includes a multitude of tables, with the most impactful showing how the nature of leadership and management changes at each stage of a career, along with what mindset you need at each stage and details of behaviours/expectations. This makes it easy to find the gaps allowing you to make an immediate impact on your mindset.

The book is packed with advice on how to get the most out of yourself and your team along with some common pitfalls for example:

• High aspirations: should not be about self – focus on the mission and gain buy-in from the team.
• The prison of performance: focus on learning, not just achievements.
• Positive thinking: ensure it doesn’t crowd out reality.
• Leadership: it’s not about authority, power or position, but taking people where they wouldn’t have got by themselves.

“High aspirations will accelerate your career: you will succeed fast or fail fast. More likely, you will fail several times, learn from your setbacks and then succeed to a greater extent than anyone thought possible.”

To paraphrase Charles Darwin: “It is not the strongest of the species that survives, nor the most intelligent, but rather the one most adaptable to change.”

This book will help you make sense out of the nonsense you might experience, and give you insight that will help you to accelerate your learning and career.

“The most important mindset for a successful career is learning and growth. If you stay still, you will fail.”

AA 50 Walks

Posted: Jul 18, 2021 in Book Reviews, Psychology
Tags: , , ,

Looking for a new hobby, some exercise, a good way to reflect on how the week went and prepare your mindset for next week?

How about hiking on Sundays. It’s taken us 3 years to get through this book and we couldn’t recommend it highly enough – short walks, long walks with breathtaking views, walks for the whole family and the dog.

The only rule is you can only use your phone for taking pics or if you get lost!

AA 50 walk guides: https://www.amazon.co.uk/s?k=aa+50+walks&sprefix=aa+50&ref=nb_sb_ss_ts-doa-p_1_5

Is there a way to get value into customers’ hands early and often?

Is there a way to deliver high-quality software on time, every time?

Is there a way to innovate at scale as the company grows?

Absolutely yes to all of these questions and Roman Pichler explains how this is possible in under 120 pages in this book.

Whilst there has been a huge uptake in businesses adopting Scrum – the most popular Agile framework over the past decade, some are still asking these questions after falling into various pitfalls, where Pichler addresses them all eloquently in his book, for example:

• Having too many handoffs of requirements/solutions/decisions which disempower the Scrum team
• The product owner only focusing on tactical work
• Not coaching product owners to set them and the Scrum team up for success
• Focusing on outputs over outcomes

If you are currently playing the product owner role, can relate to any of the pitfalls above and would like a mentor to help fill in your knowledge gap, DM me and we can solve it together whether it’s mock customer interviews, working with qual/quant data, time management, roadmapping, prioritisation, how to define a vision, missions, objectives and strategies for a product or any challenges you’re facing.

This book is an essential read for CPOs who are still struggling to experience the benefits of Agile, as well as anyone who’s playing the product owner role.

Before reading this book I’d read a few snippets in other books around Toyota’s Lean way of working, but this book tells a comprehensive story not only about the success behind Toyota’s legendary customer-centric product development techniques along with market performance data to back it up, but it was also fascinating to get insight into how the business got out of its comfort zone to innovate effectively with the Lexus and Prius.

If you’re an advocate for an empowered and learning culture, you’ll love this book as it’s packed with inspiring examples of how their success started with a healthy culture and a long-term philosophy.

This book gives insight into how Toyota creates an ideal environment for implementing Lean techniques and tools by:

  • Fostering an atmosphere of continuous improvement and learning
  • Satisfying customers (and eliminating waste at the same time)
  • Getting quality right the first time
  • Coaching leaders from within rather than recruiting them from the outside
  • Teaching all employees to become problem solvers
  • Growing together with suppliers and partners for mutual benefit

I’ve put some product principles together to help with alignment and decision-making which might inspire you when setting yours:

  1. We listen to our customers daily, have empathy for them and act on key insights
  2. We understand the market and our customers’ needs
  3. We work with the rest of the business together to solve the highest priority problems and opportunities in a lean way
  4. We build quality products and features that customers love; recognising that delivering customer satisfaction will grow the business
  5. We have clear product ownership where we are empowered to deliver excellence aligned to the business goals
  6. We trust by giving autonomy at every level across the product delivery lifecycle
  7. We spend time celebrating successes and continuously learn
  8. We acknowledge that there is no bad question or wrong answer and have an inclusive mindset
  9. We see mistakes and failures as a learning experience
  10. We have a strong product organisation, which enables us to achieve our ambitions

This book was a fascinating read where Grove talks about how he pulled off the greatest transformation in the history of Intel: moving from the memory business to microprocessors more than a decade after its founding.

During his tenure at Intel Corporation, he described the different reorganisations that the company went through, with the only one which was effective – which just about every large company or enterprise that he knew was organised was in a hybrid form, which consisted of mission-oriented departments. This reminding me of product lines.

Although it was published over 25 years ago, the management practices are timeless, where Grove touches on the negative impact of ‘managerial meddling’ (disempowerment) and he talks about productivity, work simplification and leverage with the goal to work smarter, not harder!

As Grove says “..the single most important sentence of this book: The output of a manager is the output of the organisation units under his or her supervision or influence”.

The key to survival is to learn to add more value, which is ultimately what this book is about.

A classic book on management, which I’d recommend.

In a startup, it’s common for the c-suite to function as the product manager until product-market fit has been validated.

Once validated, it’s time to build the product for real which would require a product manager to work in a product team that also includes a product designer and several engineers to continue learning and solving customer problems/demands.

As the product grows, so does the business and resources, then before you know it, the product manager is running around trying to keep the product afloat by keeping customers happy, growing the product, validating ideas, managing expectations with stakeholders and ensuring that the product is on the right strategic track. The full breadth of the product manager role is vast!

At the same time of growing resources across the business, it’s essential to consider scaling the product management team, but before this happens you need to define your product lines/areas/verticals, so then you can hire product managers to manage, own and be accountable for a particular product line/area/vertical.

The best way to split up your product into lines is across the core value streams/customer experiences, for example:

  • Cashier – Payment/withdrawal flows
  • Compliance – Login flows/security, regulatory flows, marketing preferences/data protection flows
  • Growth – Acquisition/CRM flows, account, and any MarTech integrations needed to achieve the growth OKRs
  • Engagement – Focusing on driving engagements
  • Community – Initiatives to drive social engagements
  • Gaming Integrations, content management and gaming experience
  • Sportsbook – Integrations, trading and betting experience
  • Web – Providing customers with the optimal web experience
  • Apps – Providing customers with the optimal app experience through the App/Play Store

The Product Manager is fully accountable for the success of their product line, so as well as defining the product vision, KPIs, strategies and product roadmap for their product line, they would also be part of an Agile product team (including a product designer and engineers) who would together manage the product backlog, execute the VMOST, product backlog items (PBIs) and test hypothesis.

Now, letting product teams manage a specific product line (which comes with ownership (autonomy and empowerment)) can be a terrifying thought for some businesses since they often prefer a more controlled project management approach, which is why they just hire product managers (or product owners) and stick them in a scrum team to execute projects from a pre-defined roadmap. Marty Cagan articulates this widespread problem and its impacts well in his recent article on project teams vs. product teams.

Saying this, there are also some challenges when transforming to a product line structure:

BenefitsChallenges
Clear product ownership across the businessManaging cross product line/area dependencies although tools such as Aha! certainly helps
Accountability for KPIs and live product supportMore effort needed on alignment especially on high priority cross-cutting initiatives
AutonomySwitching to a more learning, trust and empowered culture which isn’t always quick and easy
Empowered product teams
Focus on outcomes over outputs
Domain expert knowledge
Efficiency
Ability to continually improve key product areas staying ahead of the competition
Leaders at every level
Product/tech team retention

Essentially, what product lines give you if done effectively, is empowered mission-focused Agile product teams who are motivated to execute the VMOST which they defined for their product area in collaboration with key stakeholders.

The outcome of this is having a best-of-breed product, delivering more customer value quicker.

This is the best book I’ve read on #Lean.

The #LeanStartup and The Startup Way by Eric Ries were also great reads, but this book by Cindy Alvarez is a condensed version of both of them with practical step by step guides on execution, where no gaps are left when it comes to understanding how you can build products in an efficient way that customes will buy.

Whether you’re in a large enterprise with existing products or a startup, Cindy provides great examples of the benefits of using Lean principles to streamline your product development process in order to deliver more value.

This book is for:

  • Product managers, designers, and engineers who want to increase the chances of building a successful new product or new feature
  • Product-centric people in large organisations who are struggling to help their organisations move faster and work smarter
  • Entrepreneurs seeking to validate a market and product idea before they invest time and money building a product that no one will buy

Since the pandemic has caused more people to install webcams and with innovative solutions like UserZoom and Lookback to connect, it makes it easier more than ever to validate hypothesis and speak to your customers weekly to gain valuable insights.

There’s a lot of confusion around product management job titles, seniority, and hierarchy. This has become more prominent since organisations started creating the Product Owner job during their Agile transformation using the Scrum framework, even though Product Owner is a role that a Product Manager plays rather than a job in itself. This makes it hard to compare jobs, plan your career, and attract the right talent to your team.

Inspired by Mind the Product, in this article I’ll walk through the product manager levels, providing overviews for each product role, and some useful content to refer to.


Associate Product Manager (APM)

This is an entry-level product position, for someone who is brand new to the role.

An APM can be a recent graduate who would enter into a rotational apprenticeship program across the business. The aim—similar to most apprenticeships—is to develop these candidates into full-time positions through a combination of training and hands-on involvement with real projects.

Alternatively and the most common route, an APM has some work experience under their belt already and can come from any background. Engineering, marketing, design, or commercial are the most common backgrounds.

The APM works with a product development team under the leadership and mentorship of a product manager, where they would focus on learning the full breadth of the Product Manager role whilst on the job.

Typically an APM would need 3-5 years of experience before progressing to the next level as a Product Manager.


Product Manager (PM)

The most common job title of a product manager can span a wide range of experience, responsibility, and skills. Broadly this is someone who operates independently, leads the work of a product development team, and is responsible for a product line or customer journey. Because it’s the most common title, it’s important to consider what product they manage.  For example, if they’re a product manager for Facebook’s news feed and impact billions of users, they’re probably more senior and experienced than a product manager at a brand new startup.

To be clear, the Product Manager is fully accountable for the success of their product line, so as well as defining the product vision, KPIs, strategies and product roadmap for their product line, they would be part of an Agile team managing the product backlog and working with the engineers to execute the product backlog items (PBIs) and test hypothesis.

For some insights on the Product Manager role see ‘How do you Become a Product Manager?’ by Liam Smith and discover what it is that Jase Clamp believes really makes a Product person in ‘What’s in the DNA of Product People?’.

Similar to the APM role, after 3-5 years as a PM you can expect to take the next step to become a Senior Product Manager.


Senior Product Manager (SPM)

A senior Product Manager does the same thing as a product manager but has a senior title either in recognition of their contributions, the relative importance of their product, or reflects the fact that they also spend time coaching product managers. The Senior Product Manager is hands-on with a product line and also has some line-management responsibilities.

Once you’ve been a PM/SPM for at least 7 years and at least 2 of those has involved line managing/coaching other PMs, then you’re ready to take the next step up to the Lead PM or Head of Product of a specific product line eg. Head of Product – Rewards, Head of Product – Engagement or Head of Product- Gaming.


Principal Product Manager (PPM)

This is a newer role, and usually a very senior product manager who is responsible for a critical product in the company. This can be equivalent in rank to a Senior Product Manager through to a VP Product. The difference is they are not managing other product managers at all — they are simply exceptional product managers who want to stay hands-on and leave people management to others.

In many ways, this is similar to the Architect track in engineering (in contrast to the CTO track), and something we should encourage more. Just because you’re a great product manager and want to advance in your career, it doesn’t mean you should have to move away from being a hands-on product manager to a leader of other product managers. Some people are just better suited to one path than the other. Recognising who is great at leadership and who is great at building amazing products is equally important and valuable to an organisation.


Product Lead / Lead Product Manager / Head of Product – [product line]

This role is more common in larger companies with more products and management layers. Whilst this role does focus on managing other product managers, a significant amount of time would be spent supporting Product Managers with their product line vision, strategies, market analysis and execution, helping improve the product organisation structure, leading Lean initiatives to reduce waste across the business and work on cross-product line strategies.

At this level you’d have been exposed to working across multiple product lines, line management/coaching PMs and being even more dynamic, so after 3 years of being at this level, you’d be ready for the Product Director / Head of Product role.


Product Director / Group Product Manager / VP Product / Head of Product

This is where the role starts to change. It goes from an individual contributor who manages a product line and works hands-on with engineering and design teams, to someone who has stepped back from the day-to-day to focus on leading other product managers and working on alignment. This is where soft skills around people management become a critical part of the job.

After being a Product Director for at least 3 years, it’s time to take the final step up to be the Chief Product Officer.


Chief Product Officer (CPO)

A Chief Product Officer is the most senior product person in an organisation. They usually manage more than one team of product managers and represent product in the C-suite or management team. They’re responsible for overall product strategy and alignment within their teams and with other parts of the organisation.

The difference between a VP Product and CPO in smaller companies isn’t huge, and the title is used interchangeably for the most senior product person in the company. But in larger organisations that have both roles, we can again borrow from our engineering friends to clarify the difference. The VP Product is responsible for the team, the processes, and getting things done, while the CPO is responsible for the overall product vision, product architecture, and overall organisational alignment.

In ‘Where Does Product Fit? What’s Being a CPO Really Like?’, Zoopla’s CPTO Dave Wascha shares his take on the reality of the CPO role, where Product fits within the organisation, what skills product managers need to be successful, and more. You can also learn how Ashley Fidler went from a PhD in Linguistics to a CPO at Eigen Technologies in her instalment of How I got my job.


One size does not fit all

Most companies don’t need all these tiers of course, so it’s important to think about how this fits into your organisation. At a startup, you might have a single Product Manager. As you grow, a couple of Product Managers could report to a Head of Product/VP Product. Only as the company grows and the suite of products grows do you need to consider more layers. As with anything else in product, these team structures and tiers should be aligned with customer needs. This way, you can incentivise and organise teams in alignment with your company goals.

Structure = Clarity

Having clear and common structures for product management job titles in our teams will help us all better understand our careers, roles, and teams. This structure should provide the right foundation for you and your teams to ask: Do your team’s titles accurately reflect their jobs? Are they clear enough that applicants looking at your open vacancies know what you’re hiring for and if the job is for them? Or do you need to rethink your structure to maximise clarity?

Loved this book!

The way Yu-kai Chou has combined the game mechanics and behavioural psychology components to create the Octalysis Gamification Design Framework is remarkable.

The book gives a thorough overview of how you can optimise the below 8 core drivers of Gamification with Human-Focused Design to create engaging and successful experiences in your product, workplace, marketing, and personal lives.

  1. Epic Meaning & Calling
  2. Development & Accomplishment
  3. Empowerment of Creativity & Feedback
  4. Ownership & Possession
  5. Social Influence & Relatedness
  6. Scarcity & Impatience
  7. Unpredictability & Curiosity
  8. Loss & Avoidance

It reminded me of how commonly used gamification mechanics are outside of games, when my RunKeeper app told me that my last run at the weekend was my 34th fastest – a reminder I need to get out more!

The book categorises the 8 core drivers into White Hat and Black Hat techniques and explains the benefit of cultures where people are intrinsically motivated rather than extrinsically.

An enjoyable learning experience and a recommended read.