Posts Tagged ‘Product Management’

Here are some of the product principles I’ve put together which might give you inspiration 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 which 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, 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?

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.

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.

Lean

A product team is never short of customer problems to solve or ideas to validate, so if there are activities in the idea -> customer flow which are wasteful, then this impacts delivering customer/business value, motivation and time to market.

In the middle of the 20th century, Toyota created an efficient manufacturing concept called Lean which grew out of their Toyota Production System. It is based on the philosophy of defining value from the customer’s viewpoint and continually improving the way in which value is delivered, by eliminating waste or anything which does not contribute to the value goal.

The core 5 principles for adopting a Lean way of working for a digital product are:

  1. Define Value – Understand and define what is valuable to your customers.
  2. Map the Value Stream – Using your customer’s value as a reference point, map out the activities you take to contribute to these values throughout the idea -> customer flow. Also map out all of the activities which don’t contribute to delivering customer value which is essentially waste and should be reduced as much as possible.
  3. Create Flow – Once you have removed the waste from the value stream, the focus should be on ensuring that the remaining activities which are valuable, flow smoothly without interruptions or delays, with some strategies including: DevOps practices, automation, breaking down steps, creating cross-functional departments and training employees to be multi-skilled and adaptive.
  4. Establish Pull – The goal of a pull-based system is to limit your work in process (WIP) items while ensuring that your highest priority customer Product Backlog Items (PBIs) are in a ready state for a smooth flow of work. By following the value stream and working backwards through the idea -> customer flow, you can ensure that your product development will be able to satisfy the needs of your customers.
  5. Pursue Perfection – Every employee should strive towards perfection while delivering products that customers needs and love. The company should be a learning organisation and always find ways to get a little better each and every day.

Some examples of my experience on reducing waste to deliver more customer value:

We introduced DevOps, where we optimised our release pipeline making it 83% quicker to deploy software updates to the team environment and 92% quicker to deploy builds to live.

We reduced the time to market for a new website from 18 months to just 4 weeks! This was achieved by identifying waste through value stream mapping, then using that analysis to simplify the code base and reconfigure some of the hard coded elements of the code (waste) to make them remotely configurable through a CMS.

The last example had the most impact where we merged a floor of front-end developers with a floor of back-end developers to create cross-functional high performing teams.

Good luck in your journey to become Lean!

If you’re a product owner, associate product manager or product manager wanting to understand the full breadth of the product manager role, I’ve put together a generic product manager job description, so that gap analysis can be done to learn and gain experience in your knowledge gaps, which will set you up for success in the world of product management.

It’s unlikely that you will be provided with guidance or training on the full breadth of the product manager role and it’s up to you to proactively fill in your knowledge gap by testing and learning new ways of working with your product, reading books and being curious by collaborating with different areas of the business to find out more about the customer, their role and product performance.

About the role:

The Product Manager will join the product management team and take the pivotal role of managing their product line and its outcome on the customer and business.

The candidate will manage the entire product life-cycle across their product line to solve customer and/or business problems using Agile and Lean principles, by collaborating with their cross-functional team (which also includes a product designer and several engineers), as well as key stakeholders including other product managers across other product lines, BI, commercial, operations, marketing, brand, customer support and legal / compliance teams – the Product Manager is at the heart of the business, so building strong relationships and having good communication skills is important.

The Product Manager is expected to:

  • Define, manage and share the vision, missions, KPI’s, strategies and roadmap for their product line.
  • Own and manage the product backlog, so that the highest priority PBI’s are ready to be solved / validated with a PRD / hypothesis.
  • Manage all aspects of in-life products for their product line, including customer feedback, requirements, and issues.
  • Proactively collect and analyse qualitative and quantitative data to aid prioritisation and to explain why the problem is worth solving.
  • Have a deep understanding of customers by talking to customers and customer support frequently.
  • Collaborate with marketing to continually grow the product.
  • Discover new ideas / problems in collaboration with stakeholders.
  • Drive action across the business to get time sensitive product iterations to market on time.
  • Review how time to market can be reduced across their product line using Lean principles.
  • Manage stakeholder expectations when there are multiple constraints.
  • Adapt to change quickly and creatively find ways to validate ideas with customers in a Lean way.
  • Proactively remove any impediments from getting the value from idea to the customer.
  • Clearly describe what problem we need to solve, the value and customer flows to the development teams and stakeholders.
  • Dynamically switch from live support / BAU to long term strategy on a day-to-day basis.
  • Monitor product performance daily and communicate wins across the business.
  • Monitor and research the market to understand competitor SWOT.
  • Present product performance to senior stakeholders quarterly.
  • Create and share a product delivery update every two weeks.
  • Be the player and use the product frequently including user acceptance testing.
  • Line manage and mentor associate product managers.

Overall

  • Embracing their product line knowledge and effectively sharing with other team members and stakeholders.
  • Evangelising their product.
  • Striving to make progress towards their KPI goals everyday.
  • Leading the go to market (GTM) strategy within Agile methodologies.
  • Focusing on outcomes rather than outputs.
  • Accountable for the success of their product line.

Position Qualification & Experience Requirements

  • Passionate about solving customer problems.
  • Proactive with stakeholder engagement.
  • Proven track record of managing all aspects of a successful product.
  • Strong time management and organisational skills.
  • Experience with Scrum, Kanban and Lean principles and methods.
  • Strong problem solving skills and willingness to roll up one’s sleeves to get the job done.
  • Will give exemplary attention to detail and have excellent communication skills.
  • Is creative with an analytical approach and can easily switch between creative and analytical work.
  • Outgoing, positive and forward thinking.
  • Excellent communicator of product updates, trends, priority and the rationale behind them.
  • Have an obsession with creating great products with your team that customers love.
  • Has a high EQ.
  • Become the voice of the customer – be an expert on quantitative and qualitative insights.
  • Experience with tools such as Tableau, Aha!, Google Analytics, Mixpanel, Jira, Confluence, Lucidchart, Firebase or other equivalent tools.

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.

As 2020 came to an end, I reflected on how I fell in love with books at the start of 2019.

After reading Kaizen by Sarah Harvey and the way I digested the contents and reflected, gave me inspiration to continue…which quickly came into a constant hunger to learn from other people’s experiences and beliefs when it came to product management, leadership and personal development, which has helped me validate, improve and shape my understanding.

The top 3 books which made the most impact / I’ve learnt from most last year:

1. Managing Product = Managing Tension by Marc Abraham

2. Inspired by Marty Cagan

3. The Product Manager’s Survival Guide by Steven Haines

Roll on more learning in 2021!

In this book Nir Eyal provides a simple yet powerful model to help your customers form habits that connect their problems with your solutions.

The Hooked model focuses on:
An initial ‘trigger’
Which drives an ‘action’
Where you get a ‘variable reward’
Which causes an ‘investment’ due to reciprocation

Nir provides some fascinating insights into how companies have successfully adopted this model eg. Facebook, Twitter, Spotify, Tinder and case studies from The Bible App and Fitbod, where Nir tells his story of the personal benefits he got from Fitbod.

Social media companies and video game makers know these tactics already, but Nir wrote this book so everyone can build products that help people do what they really want, but for the lack of good product design, don’t.

A must-read for everyone who cares about driving customer engagement.

Today’s business world is one that needs more leaders, from a more diverse range of backgrounds and in this book Sarah Wood provides a practical framework to give aspirational leaders the courage and confidence to step up and fulfil their ambitions.

“We are in a relationships age; empathy delivers better business results”

The biggest reason why leaders are failing to step up is because of a confidence gap – not an ability, skills or capability gap!

What makes a good leader has changed over time, from being a dominant personality and didactic style to having leadership qualities of courage, kindness, trust, authenticity and empathy.

Sarah explains that “a love of learning, and the compulsion to continously explore new ideas and put them to the test, is one of the hallmarks of a great leader.”

“As a leader, one of the most important jobs you have is to motivate, encourage and support your team”.

Want to step up? Sarah says “the most important thing is that you get started, as quickly as possible. Done is better than perfect!”

This book is filled with advice and tips from other exceptional leaders which has made an immediate impact on my mindset, so I hope it helps you too.

Product Owner is a job role that came out of Scrum and although many organisations use it as a job title that is interchangeable with Product Manager, it’s not correct. In Scrum the Product Owner is defined as the person who is responsible for creating PBI’s and grooming the backlog, in Agile it was defined as the representative of the business, and neither entirely describe the full breadth of a Product Manager’s responsibilities.

Product Owner is a role you play in an Agile team, whereas a Product Manager is the job title of someone responsible for a product and its outcome on the customer and the business.

Now a lot of Product Owners out there are great Product Managers, and they should just change their title. But a fair number of Product Owners have simply completed a certified Scrum product owner course and are told to just get on with managing the development backlog, which sets them up to fail as they never consider the broader role. So if you’re tasking a Product Owner with the broader product management responsibilities, make sure you provide the training they need to master the full breadth of the role (and then change their title).

The structure of the product organisation and culture also has a bearing on whether you have the autonomy to fulfil the Product Manager job. When using Agile / Lean methods it should be the Agile team (Product Manager, Product Designer and Dev team) who make the key product decisions / trade offs, instead it can often be held centrally at a senior management level, where multiple Product Managers / Owners are assigned random projects from a roadmap to just execute which is a more Waterfall / Project Management approach. Those who find themselves in this situation should find haven in a more empowered/Agile/product led organisation which will accelerate their learning and understanding of the full breadth of the Product Manager job.

It takes courage to ask a question rather than offer up advice, but in this book 📚 Michael Bungay Stanier gives seven questions and the tools to make them an everday way to work less hard and have more impact.

On communication and habits, Michael says that the single biggest problem with communication is the illusion that it has taken place already and that 45% of our waking behaviour is habitual.

Michael touches on learning and explains that “people don’t really learn when you tell them something.

They don’t even really learn when they do something.

They start learning, start creating new neural pathways, only when they have a chance to recall and reflect on what just happened.”

“When we take time and effort to generate knowledge and find an answer rather than just reading it, our memory retention is increased.”

The book is structured around seven key questions…

🔸️ The Kickstart Question
🔸️ The Awe Question
🔸️ The Focus Question
🔸️ The Foundation Question
🔸️ The Lazy Question
🔸️ The Strategic Question
🔸️ The Learning Question

…but you’ll need to buy this great book to find out what the questions are!

Enjoyable short read, where Roman Pichler describes the key product leadership challenges, along with ways to use your heart and mind to work effectively with the dev team and stakeholders to create value together.

Roman talks about mindfulness and the leadership-related gains for product people it can have such as greater serenity, increased empathy and better decision-making.

To focus on the important, but less urgent work you need to “be willing to set boundaries, say no, and let go: You can’t do everything without either neglecting your core responsibilities or sacrificing your health, neither of which is desirable.”

But also success doesn’t happen by magic, as Roman explains that “in addition to embracing a can-do attitude, achievement requires effort and discipline. The better we want to become at something, the more effort we have to invest.”

Leaders need to “be a role model and exhibit the behaviour you want to see in others. Listen empathically, speak truthfully and kindly, and make an effort to be open-minded.”

A must read for both new and experienced product people.

This colossal 786 page desk reference provides a fantastic perspective for professionalising Product Management, inspired by Steven Haines vision for this profession.

Throughout the book it focused on a Cross-Functional Product Team, which most people would immediately think would be just a PO/PM and dev team, but instead it was refreshing to see product in the centre of the whole organisation and that product team including someone from marketing/sales, customer service, operations, development, legal…..also in my experience when a product manager brings this team together is where the magic happens.

Steven explains regardless of development methodology, it’s important to remember that the product manager is in charge of the product’s business, not just the product’s functionality, design or features.

“No one will bestow Product Management leadership on you. It is yours to own, to internalize, and to practice”

“Product Managers will earn greater levels of credibility across the organization when they understand and act on proven facts and relevant data”

This book will remain on my desk and I’d recommend it to any ambitious product manager.

A very timely book by Marc Abraham with Covid adding more tension to everyone’s lives.

Whilst it does take experience and confidence before you can lean into tension effectively, Marc explains that embracing tension is also not easy, but it is absolutely worth it!

Marc explains the benefits of ‘accepting radically’ with tips on how to allow your mind to accept things for what they are (and aren’t), so that you can focus your mind and energy on things you can change which result in more productive outcomes.

“Tensions are inherent to products and that we as product people should find ways to embrace that”

“Pressure is an integral part of life, work, being. We might as well accept this tension, starting with a full awareness of how we perceive tension and how others around us view our perceptions and behaviours”

“When curiosity is combined with passion in the exploration of a subject, an individual may be able to acquire an amount of knowledge comparable to that of a person who is exceptionally intelligent”

“Keeping on top of your product means continuous learning and improvement, with a relentless focus bettering your ways of working”

What a brilliant way of explaining the benefits of DevOps and Agile, through this novel by Gene KimKevin Behr and George. Spafford.

This book takes you on a journey where it articulates beautifully the problems which a lot of businesses have pre digital transformation – the politics, the waste, the chaos, the inefficiency of getting ideas to customers, lack of innovation alongside the benefits of adopting a DevOps culture and practices to solve these problems.

It amazed me how accurate the book is and brought back fond memories of the DevOps journey we went on in my previous job, the value it created and a challenging time when I had to juggle similar competing priorities all at once like Bill and Chris did with big projects relating to urgent security, compliance, stability/performance, tech debt and live issues alongside everything else all at once.

Coincidentally half way through reading we were releasing one of the biggest software releases I’ve been involved in, so it made the reading even more exciting and inspiring.

“Every industry and company not bringing software to the core of their business will be disrupted”

You can’t get a more comprehensive book on product leadership than this by Richard BanfieldMartin Eriksson & Nate Walkingshaw, where they explain in detail what it means to be a product leader, how they launch great products and build successful teams.

“For many product leaders, work life is a constant tension between delivering value to one group and telling another they can’t have what they want. Shipping product, and its associated value, is the reason these product leaders get up and go to work”

“It is not about individual success, it’s about getting the best out of others”

“What is common in high-performing teams is that they are cross-functional, collocated and autonomous”

How to identify product leaders:

🔸️ Plays well with others
🔸️ Seeks challenge
🔸️ Gets their hands dirty
🔸️ Always acts and thinks “team first”
🔸️ Is comfortable wearing lots of hats
🔸️ Displays curiosity
🔸️ Communicates well
🔸️ Possesses selling skills
🔸️ Has exceptional time management skills
🔸️ Is a visionary
🔸️ Shows equanimity/grace under fire