Posts Tagged ‘Product’

Top 5 reads which made the biggest impact:

1. Flow by Mihaly Csikszentmihalyi

Flow is the state in which you are so involved in an activity that nothing else seems to matter; the experience itself is so enjoyable that you will do it even at great cost, for the sheer sake of doing it.

2. Essentialism by Greg McKeown

Using prioritisation and WIP limits to determine what you focus on – doing more with less, having the discipline and courage to tackle the hard but valuable problems to solve. Working smarter.

3. The Scout Mindset by Julia Galef

Putting biases aside to get to the truth, being curious and having the courage to surface the most important things to focus on.

4. Radical Candor by Kim Scott

Comprehensive overview of how you can give effective feedback by avoiding being too nice or brutally honest, and instead having the right balance of just being candid.

5. Product Direction by Nacho Bassino

A well-balanced, accurate, and modern data-driven approach to product strategy and roadmapping.

Thanks to all of the authors for sharing their wisdom and to my connections for sharing their book recommendations.

Hope everyone has a nice festive break and a great learning experience next year!

Since the book publication in 2016, the Design Sprint process has become a familiar approach to efficiently solving big business problems/validating hypothesis that involve high amounts of complexity/uncertainty/risk, and Jake gives the background as to how Design Sprints originated along with an in-depth account of how they went through the process to test some ideas at Google Ventures.

Covering a variety of different experiments which they ran/problems they addressed made it a good read, including Slack (finding the best way to explain Slack to non-tech customers), Savioke Hotels (how hotel guests would react to a robot with personality, by experimenting through a robot delivering a toothbrush to a guests room), Flatiron Health (dealing with the complexities of getting cancer patients into clinical trials), and Blue Bottle Coffee (getting their value proposition clear on a new digital experience).

Design Spint Process

The book is practical, so if you’re new to Design Sprints, you’ll find it easy to create a plan which you can apply across your product as well as understand the key ingredients needed, so whilst tools have evolved to make it easier more than ever to validate a hypothesis in a remote world for digital products using the likes of Figma, Miro, UserTesting… the fundamentals haven’t changed in that you need to:

  • Collaborate with people throughout the sprint
  • Have a decision maker (normally Product Manager)
  • Identify a high priority problem to solve
  • Ideate and create prototype/s
  • Get feedback from potential customers

“When you get into a regular rhythm of listening to customers, it can remind you why you’re working so hard in the first place.”

I absolutely loved this book. Sahota provides a practical guide on how you can evolve your leadership skills to influence change within a business by developing others, focusing on the people, and having a growth mindset. Every single page is golden, and I found myself glued to the content and context behind the credible approaches, which are focused around the concept of Evolutionary Leadership.

Evolutionary Leadership is the choice to evolve oneself and develop the capabilities needed to evolve an organisation.

It’s common to hear in the business world that it’s leadership’s fault for specific problems, but the book focuses on how you can instead use that energy to focus on improving your own skills and behaviour to drive the necessary changes by taking responsibility, setting a good example, having courage, low ego, and ultimately influencing throughout the business which as a side effect drives change.

During my career in business, one of the most impactful leadership behaviours I’ve experienced is having the courage to do the right thing even if it’s hard and to set a good example, which proves to be one of the quickest ways to driving positive change and a healthy culture, so it’s been thoroughly enjoyable and thought  provoking reading a whole book about it.

“The most valuable learning is unlearning-replacing low-fidelity models of reality with more accurate ones.”

“The person who can reform themselves, can reform the world.”

“Anyone in the organisation can be leader-not just management. The only requirement is the choice to evolve oneself and have passion for success.”

“Understanding reality is a critical key ingredient for success.”

“All we can do to really learn the truth of reality is to constantly test our models and seek new ones.”

“The production capability will only evolve to the extent that organisational learning takes place.”

“Evolve people to evolve the organisation.”

Another book by the SVPG made this a must-buy for me and it’s the only book that goes into detail about the new discipline of Product Marketing.

Product Marketing’s purpose is to drive product adoption by shaping marketing perception through strategic marketing activities that meet business goals, and this book gives a comprehensive overview of how product marketing fits within an organisation alongside other marketing roles and product management, as well having practical canvases and guides to help product marketing managers define a credible GTM strategy and execute on it.

For me since I’ve had a career in marketing previously, I didn’t find the book that interesting, but if someone’s a product marketer or wants to find out more about the role, this is a must-buy!

This is the shortest book I’ve read at under 80 pages, but it didn’t need to be more as Kate got the key points and advice across perfectly-telling a story of how a new product director struggled at first by just focusing on the practical elements of product management, but then they turned the product org around by doubling down on Product EQ skills which had a knock-on effect to the culture in a positive way.

What a product practitioner at any level should be working toward is the ability to balance technical skills with human skills and as the story progresses Kate explains the 7S framework and how the seven elements of an org changes, pulls, or pushes on one element will create change in all others: Strategy, Structure, Systems, Shared Values, Skills, Style, Staff.

I specifically liked how Kate split out the product practice into technical skills (what work is done) and human skills (how the work is done) using example skills in a table.

“Product people select from a variety of tools that live in our virtual toolbox to solve a problem. Given that the technologies we’re working with are often new, there’s no sure way to solve that problem, so there’s a lot of experimentation and trial and error. Sometimes it works, sometimes it doesn’t-but teams of product people won’t know for sure until they try.”

“It takes a lot of practice, and it takes a special set of skills to be that person who can continually experiment in times of stress and pressure. It also requires a unique type of leadership and culture to empower teams to do just that.”

“Organisations with greater levels of both inherent and acquired diversity were 45 percent more likely to report an increase in market share over the previous year and were 70 percent more likely to capture a new market.”

“Deliberate reflection points-like retros-are key to organisational learning, and that individuals can perform up to 23 percent better after consistently reflecting on their work than they are by doing more work.”

Neel, Parth, and Aditya spoke to 67 product leaders from 52 companies to find out what knowledge separates interview candidates they hire from those that don’t, as well as what hard skills help Product Managers move up in their careers the fastest at their companies.

The outcome of the study is that seven areas were common across the board – Product Management’s Sacred Seven:

  1. Product Design
  2. Economics
  3. Psychology
  4. User Experience
  5. Data Science
  6. Law & Policy
  7. Marketing & Growth

The authors describe these areas comprehensively in over 600 pages, with an engaging structure to every chapter – a plethora of images and diagrams to help visualise the key points they make throughout the book.

Since the authors have worked within the FAANG network, the majority of stories told to help explain practices are from this network of digital products and their competitors making the stories relatable and easy to digest.

“Creating simple, easy-to-use products that account for humans’ shortcomings is a great way to make products that people will love.”

“So while we’ve talked at length about the importance of quantitative metrics, you can’t put on your blinders and ignore everything else. The qualitative side matters, especially for the long term.”

This is the most practical book on how to lead and build a high-performing product management organisation. It’s another classic from Haines where he rightfully refers to the importance of business acumen and how to level up in this area throughout the book.

Whilst there are plenty of product leadership books out there, there are few that focus on leading product management as an organisation and practical steps to get product teams to high maturity. The book includes plenty of visuals and charts making it easy to understand and apply learnings.

What’s covered in detail:

  • Designing an org strategy for Product Management
  • Aligning R&Rs
  • Optimising Product Management processes
  • Managing the Product Manager talent pool
  • Cultivating and shaping Product Managers with competency self-assessments and maturity scores
  • Product Mindset
  • Building a Community of Practice (CoP)
  • Cross-functional product teams
  • Sustaining Product Management
  • Product portfolio management

Whilst Haines details the full R&R of the Product Manager job, he summarises it nicely into 6 core attributes:

  1. Strategic & Critical Thinking
  2. Entrepreneurial
  3. Decision-Making
  4. Leading & Influencing
  5. Domain & Technology
  6. Data & Analytics

This book is a must-read for any product leader (head of product, director, CPO, coaches, change management).

This is the best story I’ve ever read, it’s also the most recommended, so thank you to everyone who recommended it, it finally got to the top of my wish list.

It was such a detailed personal account of Phil’s journey to founding Nike it made it so relatable, whether that’s resilience to knock-backs, hiking for a few weeks around Japan in your 20s, or pursuing a passion which society throws eggs at – I’m sure those who threw unpleasantries at his running group in the 60s were wearing Nike shoes in the 80s!

The two things I found most remarkable were firstly whilst Phil was hungry at gaining traction in the market, the majority of the book explains how his loving family supported him whether that was his dad with the initial funding, his wife Penny’s relentless support or his loyal friends (partners) throughout the toughest of times “getting help is just a part of a lifelong search for wisdom”.

Secondly how close Phil came to the business closing down on so many occasions that you have to read the book to believe it, with bank account closures, freezing funds, product to market timing issues, global supply and demand problems…

When Phil doubted pursuing his mission after extreme setbacks he reminded himself that “life is growth, you grow or die” which always got him back on track.

If you haven’t read this book yet, it’s a must read!

This book by Melissa Perri gives a great view on what it takes to transform a business towards achieving sustainable growth by developing, optimising, and scaling the product organisation.

“Product managers connect the dots. They take input from customer research, expert information, market research, business direction, experiment results, and data analysis. Then they sift through and analyze that information using it to create a product vision that will help to further the company and to solve customer’ needs.”

“Product ownership is just a piece of product management.”

“You need the discipline to move toward organizing for products over projects. Companies that optimize their products to achieve value are called product-led organizations.”

“Product-led companies understand that the success of their products is the primary driver of growth and value for their company.”

“Having a strong product leader in the C-Suite is a critical step to becoming product-led. Unfortunately, there are not many CPOs available on the market at the moment.”

“Whenever I start a new training or workshop, I say to product managers, “Raise your hand if you went back and iterated in the last thing you shipped.” Normally, 15-20% of the people raise their hands. My next question is, “How do you know that what you shipped was successful?” The answer here usually revolve around meeting a deadline and finishing with bug-free code.”

A recommendation for anyone with ‘product’ in their job title, and CEOs.

This is the most comprehensive book I’ve read on lean product development.

The thing I loved most about this read by Dan Olsen is how the techniques he exposes are relevant across the whole product life cycle, so for a new product entering a new market or an enterprise level business improving a mature product in a competitive market, making it applicable to use some of the techniques for identifying/solving problems on existing products.

The book is focused around a framework called The Product-Market Fit Pyramid and The Lean Product Process which consists of six steps:

1. Determine your target audience
2. Identify underserved customer needs
3. Define your value proposition
4. Specify your minimum viable product (MVP) feature set
5. Create your MVP prototype
6. Test your MVP with customers

The writing style makes it easy to digest and therefore easy to run gap analysis on your current ways of working to spot any improvement areas.

A recommended read for anyone interested in customer development, lean UX, design thinking, product management, user experience design, agile development, lean startup, or analytics.

Chuffed to see this come through. Special thanks to Carlton Nettleton for the fantastic support over the past couple of months. Also to Jason Tanner, Anil and Ted Dikmen at Applied Frameworks for facilitating the coaching circles, providing such a brilliant online academy hub and overall learning experience.

Thanks also to Flutter Entertainment for funding my self-development.

Whether you’re interested in learning the basics of Agile product development, product management, product ownership or you want to take your product knowledge to the next level, I’d highly recommend the Scrum Alliance certified product owner track through Applied Frameworks where levels 2 and 3 are even more practical, will validate your understanding and give you some effective tools and techniques to help you handle ambiguity, get ahead in the market, innovate, and deliver products that customers love yet work for the business.

CSPO (Certified Scrum Product Owner) Level 1 – https://lnkd.in/gTDPV68H
– Great intro into Agile product development covering the fundamentals

A-CSPO (Advanced) Level 2 – https://lnkd.in/eUDJ4rF4
– Mastering the Product Backlog
– User Stories
– Rapid Vision Generation
– Roadmapping that Works
– Hypothesis Testing
– Solving Collaboration Challenges
– Facilitation
– Inclusive Solutions
– Product Owner Stance
– Scaling Scrum & Agile

CSP-PO (Professional) Level 3 – https://lnkd.in/eHbUfBEt
– Use Cases
– Value Proposition Design
– Business Model Framework
– Product Economics
– Launching New Products
– Evolution of Product Owner
– Frameworks Master Class
– Scaling Scrum & Agile II
– Lean Thinking
– Lift-off for Agile Teams
– Interactive Instructional Design

When taking level 3 it’s worth getting the Servant Leadership module bolted onto your account, normally part of the Scrum Master course, but relevant as you progress your career and I found it the most impactful module out of them all.

Marty Cagan, Partner at Silicon Valley Group gave a “Straight Talk on Product Ops” at the Lean Product Meetup in January followed by a fireside chat and Q&A.

Over 303 other product folk attended the live session wanting to hear from Marty about product ops.

Notes from the session:

  • So many companies define Product Ops differently
  • Some of the most toxic ones are taking off in some companies, important to raise the impacts so then it’s a conscious decision
  • “Product Ops operates differently at every company” – Product School, this statement is not that helpful, it’s different in every company, but some companies have similarities
  • We can’t even agree to decide what the common role of Product Manager is in the industry, so not surprised we’re in this situation with Product Ops
  • Like Dev Ops, Design Ops, people have thought cool we’re going to provide product managers with real tools to help Product get products into production quicker

More than 50 companies got in touch with their definition of how they use product ops:

  1. The Reincarnated PMO Model – product ops facilitate planning activities, they gatekeep all of the product requests – most damaging, not all that common
  2. The Two-in-a-Box PM Model – handles the day to day tasks involved with development – it’s like getting product executives to do the day to day tasks – 2nd most serious problem, splitting the product manager role from connecting customers, other areas of the business and engineers, last thing you want to do is cut that person in half, innovation goes right down, slicing the job in half is disempowered, more damaging than helpful
  3. The Delegated Product Leader Model – Product Ops ensures our PM’s learn the necessary skills and techniques needed to connect the dots between the activities of the various product teams – like a personal coach to the product managers, this is something the VP of product (head of product) should do 1:1 coaching from an experienced product leader
  4. The Production Operations Rebranding Model – Product Ops job starts when the product /feature launches making sure that things run smoothly, they’re helping more around customer service, more like customer success ops, not really focused on product, this definition isn’t a problem
  5. The Product Marketing Manager Rebranding Model – Product Ops covers two main activities: synthesizing ongoing customer feedback from sales, services and support (GTM strategy incl. beta and early release programs). This is due to politics if product marketing doesn’t have headcount but needs all this done. This method is a good thing and feels it is a good modern definition of Product Ops.
  6. The Force Multiplier Model – best one, really empowering product teams with Qual & Quant insights, product tools eg. roadmaping and best practices, would be better moved to this new Product ops team than buried in UX team – the problem is that companies are staffing this role definition with junior people, should be more like principle product manager level. So the structure should be:

CPO:

  • Product Management
  • Product Design
  • Product Ops – to empower product teams with Qual & Quant insights, tools and best practices

Nothing new in Product Ops from the different definitions, whilst The Force Multiplier Model isn’t new it’s well packaged and it came from Melissa from Escape the Build Trap. Solves the issue where UX have insights that no one does anything about. Puts the qual/quant insights squarely in product across all product managers – a more visible place where it has real value.

The two dangerous forces behind so many weak organizations:

  1. Scaling via Process rather than Leaders through people – SAFe is a good example of this
  2. Splitting the Product Manager Job – see 2nd definition above as an example, the product manager should focus on value and viability for the customer and not get involved in QA, design etc, there are people to handle this and the business should resource appropriately

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).”

Image source here.

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

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.

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. 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) / Product Executive

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 be Lead Product Manager.


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 / Group Product Manager

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/coaching 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 / VP Product / Head of Product

This is where the role fully goes from an individual contributor, 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?

The most common Agile framework is Scrum, which typically involves a product manager managing a backlog of user stories (outputs) using the user story framework:

Template

As a… <persona>

I want… <intent>

So that… <benefit>

Example

As a player

I want to be able to easily access new games

So that I can have fun playing the latest games that I haven’t played before


Since user stories are output-focused rather than outcome-focused, it becomes easy to fall into the build trap of delivering output after output with no understanding of whether it delivered any value to the customer or business. One of the reasons is that unless tracking is part of the DoD, to track the value would often require additional tracking user stories in the product backlog which are easily ignored when in a project led environment or when there is pressure to get after delivering a new unrelated user story (output).

Now, In the 1920s, Ronald Fisher developed the theory behind the p value and Jerzy Neyman and Egon Pearson developed the theory of hypothesis testing, which as a result formed an Agile/Lean technique called Hypothesis-Driven Product Development which is outcome-focused, delivers a measurable conclusion and enables continued learning. A hypothesis framework consists of:

Template

We believe… <capability>

Will result in… <outcome>

As measured by… <KPI>

Example 1

We believe that by providing players with an easy way to access new games

Will result in an increase in game plays

As measured by a higher number of game plays per player and new game engagement

Example 2

We believe that by offering new players a 5 day achievement-based promotion

Will result in new players retaining longer

As measured by a decrease in churn rate by 5%


The immediate benefit of using a hypothesis-driven framework especially for uncertain product iterations is that the product team are forced to ensure that the outcome is measurable before delivering the output/feature. Since it will be measurable, it will be possible to learn and validate the hypothesis aka validated learning.

The ideal scenario would be to run multiple experiments concurrently to reach the same outcome so that you can learn quicker (rapid experimentation). A test failing means progress, that you’ve learned what doesn’t work, so you can progress in a positive way to experiment on a different idea to solve the problem.

It’s easy to migrate from the Scrum to Kanban framework or vice versa, but migrating to the hypothesis-driven framework is significantly more challenging as it involves a culture of empowerment and learning, with trust and patience being critical elements to start with whilst the team gets used to the new framework, data structure and the validation capabilities, which is needed before the product team can conduct rapid experiments effectively.

If you are entering a mature market and you are more certain that the solutions will solve the problem, a standard user story is more appropriate, but the most efficient way of delivering outcomes where you are uncertain that the solution will solve the problem is hypothesis-driven product development, rather than spending months guessing with user stories without any learning.

With tools available to easily conduct remote customer interviews (UserZoom, Lookback.io), A/B testing (Firebase, Maxymiser) and prototyping (Sketch, Figma), it makes it easier more than ever for empowered product teams to efficiently conduct experiments to validate that the solution will solve the problem.

Good luck in your experimentation journey!

Mmp

MVP (Minimum Viable Product) – the minimum amount of features needed to validate the business hypothesis with target customers.

MMP (Minimum Marketable Product) – the minimum amount of additional features on top of MVP which will allow marketing to start growing the product.


Validated learning is one of the five principles of the Lean Startup method and the MVP technique aims to test the business hypothesis. MVP was introduced in 2001 by Frank Robinson but popularised by Eric Ries through his book The Lean Startup.

Since startups tend to work under conditions of extreme uncertainty with limited resources, validating the hypothesis with target customers early in an efficient way using a prototype, wireframes, surveys or marketing material becomes even more important if it is to avoid the scenario of spending months or years building a product which customers don’t need or want (does not have product/market fit).

Achieving product/market fit would involve multiple iterations on the MVP based on target customer feedback, but once the product/market fit is validated it’s time to build the product for real and head towards an MMP by adding features to enable marketing to start growing and scaling the product, with the first set of additional features usually focusing on MarTech and improving the core customer experience.

Now, with an Agile mindset of iterating frequently based on value, it makes the MVP technique similar to Agile product development – building a product that customers need, want and loves by frequently talking to customers/target customers and we only need to look at three of the twelve Agile principles (also introduced in 2001) to see this:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Simplicity–the art of maximizing the amount of work not done–is essential.

Welcome changing requirements. Agile processes harness change for the customer’s competitive advantage.

Because of this, I prefer to use a broader definition of MVP: the minimum amount of effort needed to learn. This is because you can apply the MVP technique (Agile mindset) to a multitude of scenarios outside of launching a new product at a startup where you get the same benefits of reducing wasted money/effort/time by learning sooner rather than later, whether it’s a:

  • New Product – validate before building the whole product
  • New Feature – experiment rapidly before building and rolling out the full feature
  • New Process – being inclusive/gaining feedback before a full roll-out
  • Retrospective – ensure teams are empowered to make changes before having retros
  • Complex Solutions – start discussions early with assumptions before waiting for concrete answers
  • New House – view before purchasing
  • New Job – research/interview before accepting a job
  • New relationship – dating before marriage
  • New Car – test drive before purchase

Start small and fail fast!

Adding a new feature to an existing product is the most common scenario where you can use an MVP approach, but also where it’s most common for businesses to spend months building a new feature that turns out to be low value to customers. Similar to a new product, it’s important to validate new features where the projected value is uncertain by building a lightweight prototype/wireframes to validate with target customers when conducting interviews.

Saying this, if you have qualitative/quantitive data which gives high confidence that solving the problem will be valuable and time to market is important, then it’s equally effective to just develop and go live with the basics you need for the new feature to function at the right quality, then iterate in an Agile way.

When there is uncertainty, break it down, start small, test and learn quickly and it’s surprising how much easier and efficient the problem is to solve.

With tools to easily conduct remote customer interviews (UserZoom, Lookback.io), A/B testing (Firebase, Maxymiser) and prototyping (Sketch, Figma), it makes it easier more than ever for empowered product teams to efficiently conduct experiments to validate that the solution will solve the problem.

Once you have validated that your product has market fit and you begin to scale, it won’t be long until the product roadmap starts to fill up with valuable product iterations. Soon after that, there will be an appetite from the c-suite to understand how the value on the roadmap can be delivered sooner.

Having to balance solving customer problems, MarTech, tech improvements, tech debt, regulatory, security, bugs, innovation and dev ops requirements with only one development team would make this extremely difficult, as there’s little room to work on some of these different types of work concurrently eg. customer problems concurrently with the more technical driven requirements to improve efficiency.

In order to deliver more value sooner and work on different sets of requirements concurrently, the product would need to scale which would involve adding additional product development teams to the product line. With more development teams working on the product would also require additional firepower from the technical architect and product manager role if delivery is to remain efficient and Lean.

An example of how you can scale the product manager role across multiple development teams who are working on the same product line:

Chief Product Officer (CPO)

  • Managing the Lead Product Managers (although there is often a Product Director to help with this)
  • Handling the high level product vision for the overall product

Head of/Lead/Senior Product Manager of the Product Line(s)

  • Market analysis
  • Product organisation improvements
  • Leading Lean initiatives to reduce waste across the business
  • Cross product line strategies
  • Customer analysis
  • Qual / Quant data analysis
  • Product line strategy
  • Product vision
  • Product roadmap
  • Capacity planning
  • Coaching / supporting product managers

Product Manager / Associate Product Manager working with the Development Team within a Product Line

  • Contributing to the product vision, roadmap and strategies
  • Qual / Quant data analysis incl. conducting customer interviews
  • Backlog prioritisation
  • Epic / feature scoping
  • PRDs
  • Requirement workshops
  • User story definition
  • Detailed acceptance criteria
  • Backlog grooming
  • Sprint planning
  • User acceptance testing
  • Retrospectives
  • Daily stand-up
  • Live product support

The Associate Product Manager could also be referred to as a Product Owner, Junior Product Manager, Product Executive or Business Analyst.

In order to have the necessary focus on the product vision, managing stakeholder expectations, quant/qual data analysis, prioritisation and product strategy, it’s important that when adding additional development teams to the product line that the product manager gets more support too, or otherwise the development team could easily fall into the build trap and start delivering features which customers don’t want or need.