Archive for the ‘Guides’ Category

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!

Vision

It’s worth spending time creating a compelling vision statement because it’s something that will be repeated over and over again as it’s the key driver to drum up excitement, passion, investment, confidence and trust that the product direction is aligned to the business, solving a real problem and then, in turn, delivering significant value for the business and customers.

First things first, craft your vision statement which should only be one clear sentence, wherein a nutshell it should explain what you’re looking to deliver, to who and why:

Vision statement

Then create a product vision board specifying who the target market is for your product, problems the product solves, clarifying what the product is and how the product is going to benefit the business and customers:

Vision board

Lastly, having a vision diagram is a great way of providing stakeholders and the business with a visual image of the status of the product capabilities of where you’re at with the product today and where you’re heading. Having colour coding for ‘live’, ‘in progress’, ‘planned’ and ‘to do’ would cover it – there are plenty of mind map tools to help you visualise your product, one of which is Lucidchart which comes as a plugin for Confluence also. It’s important to keep the product diagram focused on high-level features rather than detailed technical solutions around systems as that would be more of a technical architectural diagram:

Vision diagram

Having a solid product vision isn’t just to help the business allocate resource, but it’s also essential for the development team to know exactly where they need to head and why.

Once you have a compelling product vision, it’s time to find out how to get there by creating your VMOST!

Strategy

VMOST = Vision, Missions, Objectives, Strategies and Tactics


Each product line should have a clearly defined product vision, KPIs and strategies if it’s expected for the development team to deliver outcomes/head in the right direction, and using the VMOST canvas is an effective framework of showcasing what these are in a clear and concise format.

Vision: An inspiring statement which typically should only be one sentence, wherein a nutshell it should explain what your ambition is/what is your end goal of the product and who it’s for. More info on creating a compelling product vision can be found here.

Missions: To achieve the product vision, there would be multiple high-level missions you need to go on – what are the biggest problems that need solving before achieving the vision.

Objectives (KPIs): You can track the progress of your missions by setting multiple objectives (aka KPIs), which would include measurable metrics.

Strategies: Initiatives that would deliver/impact the objectives (KPIs).

Tactics: Multiple ideas (Epics) which would deliver each strategy. The tactics should be laid out on the product roadmap, so there’s a nice link between the product VMOST and product roadmap.

Although the product manager is responsible for defining and managing the product VMOST, it mustn’t happen in a silo, as it takes collaboration with the rest of the business especially stakeholders/BI/customers/tech to help provide some guidance on the selection of problems to solve which would be represented on the VMOST.

Once the VMOST is ready, it’s time for the product manager to evangelise this in a passionate way across the business and perhaps print it out on A0 to sit near the Product/Agile Team on the wall, so it can always be top of mind.

Good luck in creating your VMOST!!

Once you’ve defined a compelling Product Vision and VMOST, you will need to map out the ‘what’ and ‘when’ and the Product Roadmap is a great way of visualising the journey.

The Product Roadmap is also a good way of managing expectations with stakeholders, a great visual to collaborate over and view dependencies, as well as giving assurance to the engineers that you do have a well thought out data-focused plan rather than changing your mind daily based on who shouts the loudest.

Key points of a Product Roadmap:

  • It should be at a high-level eg. Epic, feature or iteration level – Epic level is a preference as then it maps nicely to the teams’ product backlog items (PBI) under the epics.
  • It needs to include dates spanning the next twelve months whether monthly or quarterly.
  • The bars on the chart show when items start and when the development will be complete (live hidden).
  • One of the most important things is to educate development teams and stakeholders that the drop dates are an intent (not commitment) of focus/delivery and that things will change, so it’s advisable to avoid spending significant amounts of time making each item exact, as the desire from the business would be to have a rough idea of the twelve-month view rather than knowing whether something starting in six months will be delivered exactly a month later than that for example.
  • The roadmap needs to be easily accessible by anyone in the business where they can use their network login and can also access it from outside the office eg. on the train – if it’s hard to access, people just won’t view it and assume there’s no plan.
  • It needs to be updated frequently – if it’s regularly out of date, again people just won’t access it.

Product Roadmap examples

Roadmap sample 1

Roadmap sample 2

The most important purpose of the Product Roadmap is for you to provide a sign of intent for when product items will be delivered over the next twelve months (your journey to reach your goals/product vision), with the keyword being ‘intent’ here ie. Not an exact drop-dead delivery date. Product Managers with experience of the teams’ velocity could use gut feel also which is acceptable or rough t-shirt sizing from the lead developers, rather than dragging the dev teams away for hours/days to roughly size big pieces of work which will either 1. Change anyway and 2. Be extremely inaccurate as unknowns result in estimates going through the roof.

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.

Bubble: Bitcoin (Crypto) becoming a mainstream payment method and that Crypto is decentralised.

Revolution: Private blockchains used to improve supply chain efficiency for businesses and Crypto being a viable investment, as well as used as a payment method for large/international transactions.

Walmart used IBM’s Food Trust private blockchain to improve the efficiency of their supply chain making over a hundred thousand-fold speed improvement from farm to Walmart. Microsoft with the Xbox also made significant efficiency gains by implementing the same private blockchain strategy to improve the royalty settlement and new publisher flows.

Microsoft Azure, Amazon Web Services, Oracle, Google Cloud and IBM already offer private blockchain solutions.

Zynga, Etsy, Microsoft, Burger King, KFC, Virgin, Expedia and many others already accept Bitcoin payments.

The stock exchange industry could save $20 billion from blockchain-based clearing.

There is 1 in 66 billion trillion chance of someone mining a block (which is used to validate transactions and receive a Bitcoin reward for their effort).

Whilst only 21 million Bitcoins will ever be available (3 million left to mine), each Bitcoin is equal to 100 million Satoshis, with a Satoshi being the minimum amount you can exchange, making it an investment for everyone.

To verify a single Bitcoin transaction uses enough electricity to power an average household for 22 days and generates the same carbon footprint as over 750,000 Visa transactions.

In order to mine, you need a mining farm (a set of super computers) which are primarily owned by a small group of people that are employed and funded by a single company. Also China owns 80% of the market for Bitcoin mining hardware which is being integrated with the monetary system, adopted by banks, and regulated by governments…so not so decentralised.

Bitcoin can only process about 3 transactions per second, Ethereum 15 per second and Visa 45,000 per second.

To send $10 from US to Indonesia it’s impossible via bank transfer, costs $30 via UPS and only costs $1 via Bitcoin. To send $10k the fee is $400 via bank transfer, $150 via UPS and still only $1 via Bitcoin. In fact, it would still be just $1 fee via Bitcoin if you was to send $10m whereas the fee via bank transfer would be $400k.

Crypto exchanges already support KYC and AML regulations, making it  ready for iGaming and other highly regulated industries.

“The two biggest use cases for crypto going forwards will be payment methods (primarily for large or international transfers) and investments (supplementing, but not replacing, stocks and bonds).”

In this book, Neel Mehta, 🚀 Adi Agashe and 📍 Parth Detroja break down this highly complex set of tech into a digestible, balanced and comprehensive guide, which I’d recommend to anyone who doesn’t know about the benefits, challenges and future of blockchain and cryptocurrencies.

Lastly it was nice to hear that the creator (Satoshi) of this innovative tech is a fellow Brit.

Less

LeSS (Large Scale Scrum) is an agile framework for 3-8 Scrum teams, but when there’s more than 8 Scrum teams it’s time to think about adopting LeSS Huge. So let’s look at the differences.

LeSS
LeSS is a scaled up version of one-team Scrum, and it maintains many of the practices and ideas of one-team Scrum. In LeSS, you will find:

In LeSS all Teams are in a common sprint to deliver a common shippable product, every sprint.

LeSS Huge

Less-huge

What’s the same as the smaller LeSS Framework:

  • One (overall) Product Backlog
  • One Definition of Done
  • One Definition of Ready
  • One (overall) Senior/Lead Product Manager
  • One Sprint

So what’s Different?

  • Area Product Managers
  • Area Product Backlogs
  • Area Product Vision
  • Set of parallel meetings per Area

It’s important to remember that these frameworks are just guides and every business has their own org structure, so it’s completely acceptable to mould a framework to suit the organisational structure and industry sector.

Pipeline

With a long list of ideas / problems (features) to solve, there needs to be a solid view of exactly where features are in the idea to customer flow, so that anyone can view the status of a feature anytime without constantly asking.

Having a ‘feature pipeline’ report also proves helpful when providing stakeholder monthly / quarterly product updates.

A feature pipeline typically has multiple columns similar to a Kanban view, but it’s important to keep the content at a high- level (feature / epic) rather than stories.

Pipeline

Example Feature Pipeline Format

Some of the columns you’d have on a Feature Pipeline would be:

  1. ‘Idea’: which would be a long list of features sorted by value
  2. To Be T-Shirt Sized‘ (WIP 5): top 5 highest value features move over to a sizing column – in order for the idea to be prioritised on the product roadmap you need a rough size. It’s recommended to have a WIP (work in progress) limit
  3. Capacity Planning‘: once the feature has been roughly sized, it’s then possible to analyse when the feature can be worked on based on capacity and priority (value vs. effort (t-shirt size))
  4. Delivery Quarter‘: based on the capacity planner which should drive the start and end dates of features on the product roadmap, what quarter does the feature planned to be delivered in

There are plenty of tools available to visualise your feature pipeline eg. Aha! and JIRA and it’s a good idea to compliment that with a guide which includes SLAs for each stage of the pipeline and a t-shirt size mapping, so it’s clear what a ‘Small’ or ‘Large’ is for example.

Having a Feature Pipeline in your product toolkit for everyone to access when they want will help ensure that high priority ideas get to customers in a timely and transparent way.

Gap analysis

A Product Manager creating and maintaining documentation for new and existing features is just as important as those who maintain documentation in other roles especially developers.

Whether you use Confluence or other documentation software, having documentation makes it easy to provide context and clarity around the importance of getting after a particular feature whether it’s to the development teams or stakeholders.

When a new feature / problem / idea has cropped up, it becomes very useful to start documenting elements before any development effort is spent creating user stories or getting Product Backlog Items (PBIs) in a ‘ready‘ state. The key elements being:

  • One line description about what the feature is
  • Tagging in contacts eg. Product Manager, Technical Architect, Scrum Master, Stakeholders etc
  • Problem / Value including metrics / data
  • High-level requirements
  • As Is‘ and ‘To Be‘ flows which indicates where the gaps are
  • Competitor analysis if relevant
  • Actions / Next Steps
  • Technical details
  • Identifying and Tagging in dependencies

Having ‘As Is’ (Current State) and ‘To Be’ (Desired State) flows is a great way of clearly identifying where the gaps are, where you need to get to, what your competitors are doing in addition and what you need to do to get to your desired state. Having requirements visualised in this way also provides clarity of what you’re looking to achieve and becomes an easy way to digest and collaborate on the requirements vs. a long list of written requirements.

Spending time documenting the analysis of the idea / problem will help get the idea to a customer as efficiently as possible, providing clarity to the stakeholders and developers as to the ‘what‘ and ‘why‘.

With facilitating processes and tasks at the heart of the Scrum Master role, it requires someone with a proactive, helpful, motivated, can do, kind, organised and supportive mindset in order for requirements to be solved in an efficient way in the right priority order.

With the Product Manager, Developers, QAs, Technical Architect and Stakeholders all focused on getting their job done where there are clear boundaries, it needs someone to fill any missing gaps or connect them together in order to get the job done, which is where the Scrum Master comes in.

Let’s look at a day in the life of a Scrum Master:

Scrum master

Done

Once the product backlog is in a good quality condition and the product backlog items (PBIs) start moving into development, there’s a significant amount of tasks to tick off before the feature can be marked as ‘done’ and therefore ready to ship.

Typically a development team would use a ‘definition of done’ (DoD) as a reference to ensure that none of the processes gets missed off before it’s ‘done’, as each of those processes are essential and could have considerable consequences for the business and customers if it’s not done.

Some examples of what could be in a definition of done:

  • Code is reviewed by someone who didn’t do the PBI
  • Code is deployed to test environment
  • Unit tests complete
  • Feature is tested against acceptance criteria
  • Feature passes regression testing
  • Feature passes smoke test
  • Feature is documented
  • Feature has analytics tracking
  • Feature is approved by Product Manager

Missing any of the DoD processes before a feature gets delivered to a customer could result in critical bugs across the feature, causing bugs across other features in the code, bring down the product, delivering the wrong requirement or not being able to measure the outcome of the output, so it’s essential to take the definition of done seriously even if it means taking the PBI over to the next sprint resulting in potentially not meeting a sprint goal.

The Product Group London

If you’re a Product Owner or Product Manager and would like to participate in a variety of interesting product focused discussions, then The Product Group London is for you.

It’s also an opportunity to meet, interact and network with those in a similar role who solve similar problems and have similar challenges.

At the monthly meetups there’s normally a topic of the night and a featured product which gets discussed. For example, the July 2018 agenda was:

  1. Topic of the Night: Developing the role of product management – how do you develop the role of product management in organisations that either (1) have no formal product function, (2) have a product function that is not realising its potential, or (3) have a well-established function and need to develop it to the next level?
  2. Featured Product: Clear Review – Stuart Hearn, Founder & CEO

You can also:

Conversion1

Neil’s Recruitment have recently posted a fantastic Paid Search resource guide for grads, 1st / 2nd jobbers and those who are keen to know more about the ins and outs of paid search advertising.

The Paid Search guide which can be accessed here includes:

  • The conversion funnel
  • What is paid search aka PPC & where does it fit in
  • Basics
  • Free training webinar
  • Blogs & trade press
  • Things to research / understand
  • Glossary

It’s good to see recruitment companies like this going the extra mile to educate those who are new to digital advertising, which also clearly shows they themselves have a deep understanding on the subject.

Resource guide
Neil’s Recruitment have come up with some handy tips for writing your cover letter, honing your CV and helping you stand out in an interview:

NRC_RTB_V1-2

Neil’s Recruitment have recently posted a fantastic RTB resource guide for grads, 1st / 2nd jobbers and those who are keen to know more about what RTB is along with all those other 3 letter acronyms.

The RTB guide which can be accessed here includes:

  • What is RTB
  • Free training webinar
  • Blogs and trade press
  • Things to research/understand
  • Excel tips
  • Maths practice
  • Glossary

It’s good to see recruitment companies like this going the extra mile to educate those who are new to digital advertising, which also clearly shows they themselves have a deep understanding on the subject.

20130716

With such huge global reach and engaging ad formats, Facebook has now become a very powerful CRM tool.

Similar to display CRM, this activity would usually fall under the programmatic buying team. When thinking about what strategies to setup, it’s always good to discuss them first with the central CRM team.

Facebook CRM should run across both Facebook Marketplace and FBX. You can still use a consistant strategy structure which would be in line with display – remarketing site visitors who didn’t get passed the first conversion step, remarketing those who drop off during the conversion process and remarketing those who have converted (current customers).

For FB Marketplace you will need to rely on the CRM team heavily to provide an up to date list of email addresses by segment / strategy as targeting is by email addess (custom audience targeting). This can then be used for including / excluding at time of strategy setup. As well as targeting by email you can also target your existing FB fan base within Marketplace. The good thing about CRM across FB Marketplace is that you can deliver ads across all formats including mobile install ads.

For FBX, this is all cookie based so you can mirror the display setup 1-1. You can only deliver basic ads across the news feed and ASUs for FBX.

When it comes to post click performance, all clients will notice a dramatic improvement vs. display CRM (+250% CTR and +350% click to pixel / conversion event) but for CRM campaigns it’s all about having up to date bespoke creative, a reasonable freq. cap and bid to match the segment. Also it’s essential to have exposure across as many channels as possible for CRM and all of this is a priority over performance.

image

Using a DSP on a self service basis lets you set your own rules and strategy structure therefore site remarketing strategies should be completely separate from prospecting. It’s essential to separate them as the KPIs and strategy between prospecting and CRM are so different (similar to brand and generic search) – it’s a classic way of how a lot of ad networks used to over represent the real prospecting display results by including remarketing strategies within prospecting campaign results.

From remarketing site visitors who have bounced, to remarketing high value customers, the set-up should be bespoke to the segment. The further you get in the user journey, the less cookies there will be allowing you to be able to afford to be more aggressive as there’s less risk of budget getting out of control, also the further your customers get in the journey, the more you want to keep them (as their value increases):

Let’s start with remarketing people who have visited but not registered their details – a tight frequency should be implemented and reasonably low CPM.

Dependent on your user journey you should then split out your remarketing strategies by segment (which should all be list in your cookie CRM database) eg. Age, gender, country, product, user level – as the segment becomes more valuable to your business, the frequency cap should be loosened and CPM increased.

As well as the media strategies, the likes of creative and ongoing promotions are crucial for success in this area – it’s not going to help serving your high value customers banners telling them to sign up again or promote an out of date offer. A reminder of what’s currently available, what’s just launched, cross sell, RAF, special offers and what’s coming soon are the basics.

Remember, the harder you work on CRM and generally looking after your customers to avoid them leaving, the more you can afford to pay for new customers which has a positive effect on the incremental volume you can drive (referring to the classic volume price curve).