Posts Tagged ‘Business’

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

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.

Seeing content by Gary Vaynerchuk for a while now driven by passion and authenticity, I thought his book would be a good read and I wasn’t disappointed.

Like a lot of his content, he gives an authentic and passionate insight into what it takes to achieve your full potential and goals in life.

The book is loaded with questions he’s been asked over the years where he responds with concised authentic answers, with enough context to make you feel inspired and motivated.

“Pumping everyone full of confidence makes for a more creative, risk-taking environment.”

“Passion is an unmatched fuel”

“Maybe we all look for excuses to explain why we don’t achieve what we want to, and we should be more self-aware and recognize how much control we actually have over our own fate…it’s amazing how as soon as you make the shift from “I can’t” to “Why can’t I?” you go from defense to offense, and as everyone knows, the best place to score is always on offense.”

“The only effective way to truly lead is to practice and model the behaviour you want to see in others…the top has to ensure that its values, beliefs, and attitudes trickle down to shape the culture and encourage a productive, innovative, creative, and even happy environment.”

Really glad I bought this book by Noel Tichy – the inspiring stories and explanations gave me plenty of opportunity to self-reflect about my leadership capabilities, which has explained a lot and given me confidence that I’m heading in the right direction.

Tichy explains how organisations that have a Leadership Engine win because they have leaders at every level who teach others to be leaders. Teaching and learning are at the heart of these organisations.

“A crucial element in this process is that winning leaders and winning companies use mistakes as coaching opportunities rather than causes for punishment. Treating mistakes as learning experiences, in fact, is one of the ways in which winning leaders encourage others to develop edge and take the risk of making tough decisions.”

I’d definitely recommend this book.

Ops

All products will have an element of BAU (business as usual) and strategic work, where both are equally important to get after if the product is to remain competitive now and in years to come.

BAU work can also be referred to as ops (operational) work and I’ve always preferred the word ‘Ops’ over ‘BAU’ because no problem to solve should be looked at as solving it in the usual way which BAU can often be treated like. Also there’s often a stigma attached to BAU irrelevant of the business value it drives which is bonkers, so let’s look at the definitions of both:

  • BAU – work which doesn’t involve significant architecture redesign or thought, but BAU work is typically the blood line of the business
  • Strategic – work which involves a significant amount of up front technical design and often uses the latest / next generation technology. Strategic work often comes into play if there’s an architectural org restructure, the existing technical platform is no longer fit for purpose or it’s a new product

When it comes to delivering either BAU or Strategic work, there’s a couple of ways:

  1. Simply follow the same agile process which any other problem does, which includes adding a high level PBI (Product Backlog Item) detailing the problem to solve with value and then the Scrum Master / Team Lead looks well ahead in the product backlog to start contemplating approaching the ‘how’ with very close collaboration with the Technical Architect (TA) with the aim to get the item in a ‘Ready‘ state for development. This would in turn lead to the development teams planning in Technical Support backlog items to help the TA with technical designs, spikes or investigations well in advance of the problem appearing towards the top of the backlog which applies to both Scrum and Kanban.
  2. Split development resource into BAU only and Strategic only

The risk with No 1 is that the Scrum Master doesn’t collaborate with the Technical Architect soon enough resulting in the PBI hitting the top of the backlog before technical designs have started, causing significant delays to getting after the strategic work.

But there’s a much bigger risk to No 2 where there would naturally be a big reluctance for a team to work purely on BAU and therefore miss out on any green field project and there’s risk of breaking the ‘One Team’ mentality across the product development teams working on the whole product together and in turn impacting team morale.

Heart beat

In order to get an idea (problem) to a customer (solution) there can be as many as 5-8 different levels / key roles to play from Developer to Product Manager and to get the idea delivered in an efficient and effective way, it’s important that everyone plays their part and gets stuck in.

One way of ensuring that you’re delivering real value by playing a part in the idea to customer flow is by providing regular heartbeat updates to your peers and stakeholders.

Dependent on the role you play, will depend on the type of heartbeat update you’d send out:

  • Developers – all that’s required from a developer (or QA) is to update the agile software tool eg. JIRA on a daily basis which will automate any type of report eg. Sprint burndowns, sprint delivery report for the Scrum Master and Product Manager
  • Scrum Master / Team Lead – fortnightly release update on in flight product iterations (epics), risks to delivery and mitigations to be sent to peers, Development Manager and Product Manager
  • Development Manager – monthly update on delivery efficiency improvements, development recruitment and strategy to deliver upcoming product iterations to be sent to peers, Product Manager, Technical Architect and head of development
  • Technical Architect – monthly update on technical architecture solutions for upcoming product iterations and quarterly presentation on architecture vision to Stakeholders, Development Teams, Product Manager and head of department
  • Product Manager – fortnightly sprint review and sprint goals report, bi-monthly update on what product iterations are up next with a product roadmap update and finally a quarterly presentation on what value has been delivered, what’s up next and an update on the product vision. The majority of updates to Stakeholders, Development Teams, Technical Architect, Directors, CTO and head of development

Once you’ve mastered the format of your updates, actually changing the content shouldn’t take long at all, so it’s easy to send out your heartbeat updates on time, but by not sending out any updates could easily give the indication that you’re a passenger on the idea to customer flow.

To compliment the Product Roadmap, there should be a prioritised product ‘Feature Backlog’ which gives both stakeholders and the development teams a detailed overview of the Product Roadmap items still at that high level (Epics / Product Iterations).

If you use JIRA to manage your software delivery projects and you have your product roadmap items at an Epic level, then you’re able to simply setup a Kanban board with just one column called ‘Feature Backlog’ with a filter set to show only Epics and Epics which are ‘in progress’ or ‘to do’.

To visualise the feature backlog in a better way than the Kanban board, it’s possible to also show that same JIRA epic search filter across the likes of Confluence or Aha! where you can specify what JIRA fields to show.

Depending on your custom fields in JIRA, looking at the Feature Backlog should give stakeholders and development teams working on the product a high level (iteration / epic) idea of:

  • Priority order of all epics / iterations
  • Status – what’s in progress, planned or to do
  • Business value – whether it’s driving x incremental revenue, saving x money, avoiding x fees, meeting regulatory requirements, contract deadlines, tech debt, advancing technology etc
  • Description of the iteration / problem you’re solving
  • Delivery date which should match the dates on the product roadmap
  • Size of work

The Feature Backlog is a great way of showcasing at a high level the value of the product iterations which are currently being worked on and what’s planned in the next twelve months.

The Feature Backlog also helps the development teams understand the details of what problems are upcoming to solve, so they’re able to think about how to approach each epic / product iteration well in advance.

Kpi

In order to prioritise effectively you need both the projected value and effort, but these aren’t always easy to come by. Projecting value can be particularly challenging if the data isn’t easily accessible which can have a knock on effect when analysing your KPIs (Key Performance Indicators).

Ensuring that a product / feature have KPIs is beneficial for a few reasons including: Aiding prioritisation, celebrating success, feeding back on software development iterations and to feed into the general product vision and wider business goals.

Your KPIs don’t have to be a financial value (although a good attempt at projecting a monetary value should be made to aid ROI projections) or just one KPI, but they just need to be measurable, an indication of success and for them to be linked in someway to the overall business goals, so how can you identify what your KPIs are:

  • Incremental revenue – benchmarking on existing revenue volumes for the relevant feature in question. What do you anticipate increasing the revenue / ARPU by
  • How many customer queries are you hoping to reduce and how much does it cost per contact
  • Is it solving a common problem / request that high value players have been submitting
  • Will solving the problem increase website stability, reducing downtime for customers
  • Are you expecting to increase customer acquisition numbers / conversion rate
  • Will it increase retention rates – a measure of this is churn rate / drop off as well as LTV
  • Efficiency savings – by completing a piece of work could it increase team output / Velocity whether it be development or a marketing team
  • Feature traffic / usage – if conversions or direct revenue from the feature isn’t relevant then at a minimum having sessions, dwell time and value of customers using the feature can be used as a KPI

    Identifying your KPIs is one thing, but having the data available at your disposal on a self-service basis to cut, analyse and share is naturally fundamental, but once you have identified your KPIs and have access to the data, you can be confident that you’re well equipped to contribute to the Agile piece, but also your helping meet the wider business goals.

    Problem solving image

    There will never be a lack of problems to solve when it comes to product development, but handling the relentless amount of ideas and identifying the right ones to focus on can be tricky if a robust process to prioritise and track all of these is not in place.

    There are many approaches you can take to handle problems and prioritisation, some product management videos I’ve seen describe the product manager to spend most of their time saying ‘NO’ to stakeholders which I tend to disagree with, because technically all problems can be solved and an idea is never a bad idea, but perhaps it just can’t be solved right now due to higher priority work, so a response to show appreciation for raising the idea / problem and that it’ll go through the prioritisation process is a more appropriate response. Some also handle prioritisation and requests by who shouts and flaps the loudest which is equally not the way to go about effective backlog prioritisation.

    Two things you need in order to prioritise effectively 1. Value and 2. Effort to work out the projected ROI. Before you even spend effort discussing how much effort a problem will take to solve, the first thing which should be asked when someone approaches you with a problem, idea or bug is “what is the value?”. As a result of this, you may get:

    • A sheepish response where they don’t know, so they’ll have to go and find out (in some cases resulting in the problem being so small it’s not worth solving it, so you don’t get to hear about the problem anymore)
    • Value provided is minimal (relative to everything else in the backlog)
    • A fluffy response eg. It’ll increase traffic, it’ll increase retention rates etc, with no given metric
    • A significant problem / idea to solve which could deliver vast amounts of incremental revenue, benefits to customers or savings through efficiencies which should be fast tracked through the effort sizing and prioritisation process

    Another question which can be asked to identify value is “what happens if we don’t do it for 3 months, 6 months or never” which will aid prioritisation further.

    At your disposal you should have a data visualisation tool to easily view trend data and access KPIs for your products and features which is another way of identifying value for yourself, but ensuring that you and your Scrum teams are working to solve the highest value problems is fundamental in achieving a healthy ROI and successful product, so by asking just some simple questions up front will make your journey a lot more palatable.

    Team-image

    There’s no doubt that it’s desirable for a team to be happy for many obvious reasons including productivity, but a few do’s and don’ts to retain a jolly happy team ☺:
    Do

    • Be polite irrelevant of who you’re talking to – thank you, I appreciate that, thanks
    • Offer help if you see a colleague struggling
    • We have done that – embrace the team
    • Congratulate your colleagues on achievements
    • Share any positive performance off the back of effort
    • Own up / apologise for contributing to buggering anything up accidently
    • Be positive day to day
    • Be honest sooner rather than later so people have time to improve
    • Chill and take time out to talk non-shop to your colleagues
    • Discuss / focus on what problems you’re looking to solve
    • Ask why it’s valuable
    • Allow autonomy

    Don’t

    • Blame a work colleague directly but instead discuss whos responsibility it is and how we can avoid it in future
    • Dictate solutions to colleagues. discuss the problem and how you need help solving it instead. Troops will stand by and support you whatever the need
    • There’s absolutely no need or nothing to gain from being rude or a bully, other than your work colleagues keeping their distance from you. You can always get what you want from being polite and direct.
    • Focus on problems with agreed solutions (negativity)
    • There’s no I in team
    • Contradict yourself regularly to avoid confusion and frustration

    This may all be obvious, but get it wrong and there could be an expensive mass exodus which will impact productivity, but adopting at least a few of these will result in Spartans banging their swords against their shields ready to defend the realm with you.

    Not enough

    Scenario: Revenue has been declining for years and the CEO is pointing the finger at acquisition marketing to grow business. Planners are very familiar with this scenario.

    I wrote an article recently that all programmatic buying should be in-house, but if a brand is expecting that this alone will solve a decline in revenue, then they need to wake up and smell the coffee.

    With ad spend over £15bn / year in the UK alone, this brings a lot of hungry salesman to your door insisting that their product is the best and that you should invest, which puts pressure on CEO’s and CMO’s to potentially waste a lot of money testing out the same option over and over again or testing out an option which only has a 1% chance of working to key KPIs. Also accepting a post-view window across their display buys as default because they’ve been constantly told that ‘the flashy banners are driving all organics’ is something which gets banded around often. With that amount of ad spend floating about also brings an opportunity for large sums of money to change hands under desks without the brand (if it’s an agency) or without the investors finding out.

    Just because there is more hype than ever when it comes to advertising eg. programmatic buying, DSP’s and trading desks, it doesn’t mean that focus and investment should divert away from other core business areas. Many CEO’s feel that obsessing about acquisition marketing is the way forward because of the simplicity of delivering an ad which a potential customer can click on in conjunction with hundreds of salesman saying that this is the answer, but for those who are keen to work backwards – finding out why high value customers are leaving feeding this back into dev and marketing, developing products across all devices, looking at CRM and key promotions are the ones who will survive and therefore be able to afford a significantly higher CPA than competitors, giving the trading desk plenty of ad options which competitors cannot afford to buy.

    If all of the below areas work together to achieve a common goal then the long term consequence of this will be shown in bottom line results and staff retention rates in a positive way:

    Capture

    It was really nice to read Marco Bertozzi’s article the other day where he used a personal example to demonstrate that spending money on advertising isn’t the only way of generating revenue and growth.

    image

    When you look at any of the top brands which are currently doing well in this economic crisis, they are likely to have many things in common such as customer service levels, responding to customer demand promptly and delivering a high quality customer experience no matter how you engage with their brand.

    Customers are more savvy than ever and will simply not stand for bad service, not being clear with promotional Ts&Cs and a bad user journey / experience.

    Many CEO’s still ignore and turn their backs on their high value customer feedback, customer complaints, competitor improvements and general customer demand yet wonder why their competitors are stealing more and more market share.

    Due to how technology has evolved over the past few years, this has forced brands to adopt an omni-channel strategy rather than a cross-channel strategy. Omni-channel is a one unified brand experience no matter how or where you engage with the brand. Some examples of what this does and doesn’t look like:

    • You see a product in store which isn’t available online – not omni-channel.
    • You start a car insurance quote on desktop and finish it on your mobile – is omni-channel.
    • You play poker on desktop but key features are missing from the mobile app – not omni-channel.
    • You receive a coupon through the post which is only available to use in store – not omni-channel.
    • You get a very warm customer feel in store and also get a very thorough warm response over the phone – is omni-channel.
    • You thought you’d upgrade your TV sat package online and after a few months decide to downgrade no matter what, but you can only downgrade over the phone – not omni-channel.

    It won’t be cheap to adopt an omni-channel strategy, it won’t be an easy ride and it’s certainly not a short term strategy, but if you want the new generation of customers to engage and stay loyal to your brand, then you need to adapt.

    Fortunately there are consultants already out there who can offer good advice like Webcredible and IVIS Group.

    In house

    Ad agencies have offered huge value for advertisers for decades and continue to do so. This will never change.

    The key benefits of outsourcing the media planning and buying function to ad agencies include the likes of: global negotiating power, specialist contacts for sponsorship deals, cross client learnings, cross channel integration, deal with the hassle and admin and it’s someone for the CMO or CEO to blame if the business isn’t hitting key targets.

    With programmatic buying (Paid Search, Social Media, Display RTB, Online Video, Mobile and Affiliates) becoming the bulk of digital Marketing, the majority of these benefits no longer applies therefore it doesn’t make sense and can be classed as lazy if a brand wasn’t to even consider taking all programmatic buying in-house.

    Although rightfully CEO’s obsess about growth, also ‘wastage’ and efficiency across the business needs to be reviewed often.

    Let’s look at the pros and cons for taking all programmatic buying in-house:
    Pros

    • New digital media team would be sitting next to all other marketing areas eg. CRM, creative, content, web design, product managers.
    • Close to business KPI’s and budgets so they can be extremely reactive.
    • No hidden margins in bid platforms.
    • Can often get cheaper adserving and bid platform rates.
    • Team become specialists in the business sector / vertical.
    • 100% of time and focus will be given to the one client.
    • Learnings and data won’t be shared with other clients with no chance of leakage to competitors.
    • Can turn around new campaigns significantly quicker.
    • 24 hour contact.
    • Will always have the time to stay ahead of the game.
    • Work closely with the data team / in-house DMP optimising on real KPI’s such as revenue / LTV / ARPU.
    • Can openly recommend business requirements to CEO in order to get things done quickly and grow the business.
    • No hidden agendas – everyone aiming for the same goal.
    • Other internal departments can be educated about what role the media buy has on business goals.

    Cons

    • Can take six months to recruit team, train grads and setup systems and data integrations.
    • Ad agency would have to make more effort to integrate offlline and online brand with internal programmatic team.
    • The CEO might ignore team recommendations of key requirements needed to improve marketing.
    • CMO would need to find someone who has +5 years experience in programmatic buying across all channels to head up the team and train the grads.

    There are certainly plenty of pros and if you’re wondering how to kick things off, speak to some of the recruitment agencies below who will be able to provide an abundance off free advice:

    Neil’ Recruitment

    Digital Bubble

    image

    Capture

    A traditional way an ad agency generated revenue was through a variety of ways such as agency fee, adserving mark up, bid platform fee mark up and preferred partner trading deal kickbacks.

    With more and more channels becoming programmatic led where negotiating doesn’t come into it and clients rightfully continue to be protective over their data, ad agencies are finding it increasingly difficult to stop revenue declining.

    It’s becoming more popular for brands to include ad data into their existing DMP keeping the data in house and secure, take control of the adserving and bid platform contracts for further transparency and handle all biddable media / programmatic buying in house (paid search, desktop and mobile display (incl. RMTG), Facebook, Twitter, video / VOD….) allowing the brand to react quickly to ROI data and innovative new media options keeping them ahead of the game.

    So this leaves a big hole in many traditional ad agency wallets meaning they’ll have to adapt to meet the current demands of brands. So what will the focus be on over the coming years for them:

    • Offline planning and buying will always be an essential part of an ad agency even as offline including TV transitions over to programmatic buying
    • Large sponsorships will also need global negotiating power so although there will be certain levels of kickbacks, ad agencies will always get a far superior deal than a brand
    • Consultation – although many digital agency specialists will move over to client direct, there will be a need across certain brands for support in setting up custom attribution models internally, econometrics and business development (whether it’s advising the CEO to focus on app development, building out their DMP for more insightful data or improving their in house trading desk) all of which would be priced accordingly.

    Ad agencies will always be there to support brands whatever their needs, but in future it will be in a more transparent way.

    satisfied_customers

    No matter how much marketing you deliver, whether it’s billions of banners on the most premium sites in the world or you’re top of key generics consistently for Google, unless you have a stable product offering which customers genuinely embrace, then your brand has a fairly bleak future.

    Historically you could spend your way out of a crisis, but now if your site crashes often, you hide key T&Cs, mis-sell promotions, have a complex user journey, product not available on multiple devices, then in a few years time your brand value will show a clear decline which would eventually kill your business unless you adapt fast.

    I think the below video demonstrates the future in a fantastic way and how consumers will shape products, businesses and communication. The good thing about the future is that it will kill a lot of cow boys who are short sited and have no long term business strategy.