Archive for the ‘Data’ Category

A thought-provoking read which explains the impossibility of predicting a certain future, but using #experiments, working together and staying open-minded results in a more probable future.

Remarkably this book was written just before the Covid-19 pandemic!

Even though futures are impossible to predict, by having shared, passionate guiding #principles or an inspiring #vision can increase the chances of reaching our goals even with extreme uncertainty, where we only need to look at how art and cathedrals are created as evidence of this.

The book touches on how traditional management is addicted to masterplans and want safety and certainty, not creativity and risk that come with experimentation, which as a result constrains their chance to map a safer future. This section reminded me of Waterfall vs. #Lean/#Agile.

More automation is a common prediction of the future, but Margaret explains that this comes with a risk of falling into a trap: more need for certainty, more dependency on technology; less skill, more need. The more we depend on machines to think for us the less good we become of thinking for ourselves.

“Making the future is a collective activity…the capacity to see multiple futures depends critically on the widest possible range of contributors and collaborators.”

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.

Loved this book!

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

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

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

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

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

An enjoyable learning experience and a recommended read.

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.

Analytics

The short answer is yes – the product/team will definitely benefit by having web/app analytics tracking as part of the definition of done (DoD).

The only time that a separate analytics tracking story should be written and played is typically in the scenario of:

  1. There’s no existing analytics tracking, so there’s tracking debt to deal with including the initial API integration
  2. A migration from one analytics provider to another

The reason why it’s super important to ensure that analytics/tracking is baked into the actual feature acceptance criteria/DoD, is so then:

  1. It doesn’t get forgotten
  2. It forces analytics tracking to be included in MVP/each product iteration as default
  3. It drives home that having tracking attached to a feature before it goes live is just as important as QAing, load testing, regression testing or code reviews

Unless you can measure the impact of a feature, it’s hard to celebrate success, prove the hypothesis/whether it delivered the expected outcome or know whether it delivered any business value – the purpose of product development isn’t to deliver stories or points, it’s to deliver outcomes.

Having a data-driven strategy isn’t the future, it’s now and the advertising industry adopted this analytics tracking philosophy over two decades ago, so including analytics tracking within the DoD will only help set the product/team in the right direction.

Velocity

Velocity = Projected amount of story points which a team can burn over a set period

A development team’s velocity using Scrum or Kanban can be worked out by totalling up the amount of points which has been burned across 3-5 sprints/set periods and then dividing it by the periods the totals were calculated over (taking an average across the periods).

It’s important to use an average across the last 3-5 periods, so then holiday seasons and a sprint where items have moved over to the following sprint doesn’t dramatically impact the numbers as much as it would if you only looked at the last period.

A team can use their velocity in many ways, for example:

  • Understanding how many points they can commit to during sprint planning/work out how many PBIs (Product Backlog Items) could be done across the next 2 weeks
  • To aid prioritisation (The ‘I’ in ROI)
  • Predicting when software can be delivered in the backlog, which can then be used to forecast future feature delivery
  • Understanding the impact on any resources eg. Scrum team member changes or adding extra teams to the product
  • Understanding the impact which dependencies are having which can be reviewed in the retro, great example being build pipelines
  • Providing a more accurate estimate than a t-shirt size
  • As a KPI for efficiency improvements

I tend to refer to points being ‘burned’ rather than ‘delivered’ because it’s quite easy to fall into the velocity/story point delivery trap of obsessing about points being delivered rather than obsessing about delivering outcomes (business value).

Devops

Development effort isn’t cheap, but extremely valuable no matter what industry you work in, so once a product iteration is ready to ship, automating the final steps including the software build, deployment, environment and release process will help continuously deliver customer value in an efficient way without unnecessary delays or bottlenecks.

DevOps is the combination of cultural philosophies, practices, and tools that increases an organisation’s ability to deliver applications and services at high velocity: evolving and improving products at a faster pace than organizations using traditional software development and infrastructure management processes. This speed enables organisations to better serve their customers and compete more effectively in the market.” – AWS

There’s often a significant amount of thought and effort which goes into getting an idea into development, so when the code (solution) is ready to kick off the build (ship) process, it’s important that this is as automated as possible to avoid unnecessary delays with customers getting hold of the feature within a timely fashion.

Due to the rise of the DevOps culture, it’s now possible to automate the whole build, deployment and release process. As well as customers getting features sooner as mentioned above, other benefits of adopting a DevOps culture includes:

  • Software Development division remaining competitive
  • Reduction in waste from having to wait for software to build, deploy, dealing with environment issues and working with the operation team to handle the release
  • Increasing the R in ROI (Return on Investment) as less waste results in delivering more value to customers
  • Improving team morale – dealing with environmental, build and release issues manually isn’t fun
  • Improving on sprint goal complete rates as it’s less likely stories will drag over to multiple sprints because of build / release issues
  • Decreasing lapsed time of development work
  • Improved security
  • Easier to track build to release timeframe
  • Automated
  • Scalable

Adopting a DevOps culture should ideally come from bottom up rather than top down – a Product Manager shouldn’t need to create stories, sell in the importance of it to dev teams or prioritise it, as optimising the software build and release process should be BAU (Business as Usual) and should always be constantly looked at and improved.

As development teams adopt a DevOps culture and they start migrating over to a fully automated process, the benefits will be obvious and lucrative.

If a product is to be sustainable, tech fit, compliant and competitive it needs to have a short and long term development capacity strategy which will help to ultimately deliver the product vision.

Not having enough capacity could mean spending months / years only focusing on upgrading software versions / maintaining legacy technology or meeting regulatory requirements – not making any significant progress on getting after the product vision or surpassing competitors, having too much resource could mean that another product in the business could deliver a higher return with that resource instead, but having the right amout of capacity is important.

The product having the right amount of capacity should mean it’s possible to get after low hanging fruit, maintaining current tech whilst also concurrently getting after the next generation technology (product vision), meeting security / compliance requirements and having resource to experiment.

Understanding what the right amount of capacity should be isn’t easy, but a capacity planner will be able to help. A capacity planner should ideally be driven by points and velocity, so that no matter where the feature is on the feature pipeline (received a high level t-shirt size or has been broken down into stories) it’s possible to easily update the capacity planner with a more accurate estimate as the feature goes into development.

The data you’d typically need to lay out in a spreadsheet in order to effectively capacity plan includes:

  • Date (by month)
  • Team velocity – ‘Points to Allocate to Features’ (which already takes into account average sickness, holidays, ceremonies, breaks, training etc)
  • Forecast of future velocity based on an increase / decrease in capacity eg. Are you planning on adding another team to the product in 4 months time?
  • List of features
  • Estimates (in story points) against each feature
  • Priority order of features
  • ‘Points Remaining’ which is calculated as you start filling up the spreadsheet

It’s totally possible to roughly estimate future features by dev sprints, team sprints or man days instead of points as long as you convert it back to points after knowing how many points a whole team burns each sprint (velocity).

Another reason why it’s essential to have a capacity planner is that based on when features start and finish on the plan will drive the product roadmap dates making the roadmap data driven.

Having a capacity planner available is also a handy report when demonstrating to stakeholders that when features are in the correct priority order and once capacity has run out for a given month, then there’s no more room to slip in anymore work and it’s a case of being patient or changing priority / increasing capacity.

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.

Goals

No matter what product a development team works on, there will often be a big backlog full of high priority customer-centric / commercial work to deliver, technical improvements to make, bug fixing, getting after the next generation technology and security / regulatory / compliance work, so it’s important that there’s clarity over what the specific headline goals are for the development team to achieve over the next sprint / time period.

Some key points when setting goals:

  • They should be specific, but also be accompanied by a high level summary of the bigger picture
  • They should all be action-orientated
  • Make sure your goals are measurable so you know if they’re done or not at the end of the period
  • Indicate a period they’re valid for until they’re reviewed
  • Share the goals with stakeholders and senior management, as well as the review of whether the goals were ‘done’ or ‘moved over to the next period’
  • They should be realistic and the development team should agree to the goals

Setting frequent delivery goals is not only important so that the right focus is being spent on the right things which will increase the likelihood of making progress on solving the highest priority problems, but it also gives visibility of the overall progress made on product iterations and highlights problems in the process if goals are frequently not met, whether it’s due to build pipeline / environment issues or last minute dependencies for example, which should be discussed in the retrospective.

Setting delivery goals, reviewing, celebrating and learning from them should be the norm like it is when everyone’s objectives are set across the wider business.

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‘.

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.

Once you’ve created a solid Product Vision, it’s likely you’ll be asked to provide more granular details on the ‘what’ and ‘when’ and the Product Roadmap is a great way of helping you answer that.

The product roadmap is also a good way of giving the development teams an idea of the exciting upcoming features / problems to solve for the product.

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 product backlog items (PBI)
  • 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 can and will likely 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 time 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 thing about the Product Roadmap is to always provide a sign of intent for when product items will be delivered over the next twelve months, with the key word being ‘intent’ here ie. Not exact drop dead delivery date and a couple of people with experience of productivity could use gut feel which is totally acceptable, rather than dragging developers away for days on end 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.

A sign of intent for the next twelve months for the product is also better than a half empty roadmap!

Celebrate

There are always endless amounts of tasks which need doing or processes to improve, but it’s important to frequently stop to say thanks and well done to the craftsman who have created the magic.

Because of the vast amounts of items on the agenda, unless quality time is spent communicating the high valuable work which has been delivered for the business and customers it’s easy for those pieces of work to get forgotten, but when looking back at those items which did get delivered it would always be something to be proud of and something to celebrate with your fellow colleagues.

A few good ways of saying thanks and showcasing the awesome high value work the development teams have delivered:

  • Product iteration alerts – as soon as an item has been delivered, not only is it essential to let stakeholders know what has just gone live to customers, but it’s equally important to shout out the teams who have been involved in the delivery to say thanks and well done. Using some quotes from key stakeholders is a nice touch also
  • Quarterly delivery reviews – looking forward at the exciting future planned product iterations and new product launches happens frequently, but equally it’s important to take some time to look back at all of the awesome iterations the development teams have delivered over the previous few months
  • Team lunches / nights out – escaping from the office to hit a nice restaurant or bar at the end of a milestone or project delivery
  • Adhoc thanks and well done – after an important launch happens, informally gather up the troops to say thanks and well done for their remarkable achievement re-emphasising what it means for the business and customers

There’s plenty of other ways to recognise and celebrate success, but just making a small amount of effort frequently to recognise the hard work and positive impact the development teams are making will inject pride and drive into the development teams.

ScrumCards

A self-organised development team working together successfully to achieve common goals within the sprint boundary (typically every two weeks) is only possible if the teams ceremonies are done which includes:

  1. Daily stand-up – the scrum team need to meetup daily on time to discuss what they did yesterday, what they’re planning to do today, highlight any dependencies, issues or help they might need
  2. Updating the scrum board daily – whether the source of truth is the physical board or a digital version eg. JIRA, the scrum board needs to reflect the current state of play with regards to the sprint progress, so the team can understand how they’re progressing with their sprint commitments and sprint goals
  3. Regular backlog grooming sessions – in order for the development team to be able to work on the highest priority PBIs (Product Backlog Items) in the next sprint, they need to ensure they meet up regularly in order to get at least the next three sprints highest priority backlog items in a ‘ready‘ state
  4. Roughly sizing the backlog – in order to predict when customers will receive tweaks to the product, it’s important that the product backlog is roughly sized to aid delivery ETAs, but also prioritisation
  5. Retrospectives – meeting up once a sprint to discuss what could have gone better in the last sprint, what went well and what to continue doing. The format is flexible and the most important thing to do at the start of any retrospective is to focus on actions front the last retrospective – unless actions are done (the team learns), retrospectives are pointless, so it’s absolutely crucial that the things which the teams are keen to change / improve on is actioned or tried at least.
  6. Sprint review – showcasing what awesome iterations the team has been working on to get feedback and a round of applause from stakeholders

In order for the scrum team to be able to fulfil their commitments they should be getting significant help, guidance and support from the Scrum Master or Team Lead, Product Manager and the Development Manager and only once the above points (basics) are being done well, can a team start to seriously look to improve their velocity and scale successfully.

CompetitorAnalysis

Whilst it’s important to keep an eye on what your competitors are up to, it certainly shouldn’t be in the bucket of tasks to obsess about and instead competitor analysis should be part and parcel of problem solving.

Whether research suggests a specific type of financial product should be launched, a specific mobile payment method is needed, refer a friend rebrand, registration flow optimised or customer support improvements, part of the discovery phase when looking at solutions should be analysing how other companies have solved the problem (including competitors), which would give a wide range of interesting ideas to consider.

It’s equally important to not simply copy what competitors do, but instead have a vision and ambition to deliver a next generation solution leapfrogging the competition.

An important time to analyse other companies approach to a solution especially competitors is their approach to new regulatory requirements, especially as some of the guidelines are so ambiguous and taking a risk approach to some regulatory requirements comes with potential consequences, but equally come with an avoidance of revenue loss and it’s important to remember that implementing regulatory requirements isn’t cheap not to mention the opportunity cost. An example is that if the likes of Vodafone, British Gas, PokerStars, Llyods or Apple have deployed a relatively high risk approach to certain regulations, then it’s safe to say that using their solutions as a guide would be sensible. If the regulation is industry specific then using the market leader could be a good base also.

If you’re one to obsess about competitors or tend to replicate what they do, the next time you have a big change to make or problem to solve, try ignoring that any competitors exist, ignore all current technical limitations giving the development teams a blank canvas to focus on solving the real clear problem at hand and you might be blown away at the creative thinking that the development teams and UX come up with, utilising the wide variety of new technology available which surpasses anything your competitors have got live or on their product roadmap.

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.

    So many awesome ideas from so many people to improve product, but it’ll always be impossible to fulfil all desires in an acceptable time frame to stakeholders, making prioritisation not only challenging but extremely important.

    Process, data, collaboration and determination can certainly make prioritisation all the more effective and smoother, so looking at these areas in more detail:

    Process: Status of projects, where do product requests / bugs sit in the pecking order, ETA on delivery, investment cost and projected value of projects held in a transparent way will help with the communication overhead and help maintain trust.

    Data: To ensure that high value items are being worked on you need data to backup assumptions. It can be easy to flap and try to make a problem out to be bigger than it is to get it done, but there should always be some kind of data to back it up with examples being: incremental revenue which can be reverse engineered from retention uplift rates or projected acquisition volume increases using ARPU for example. Other ways of projecting value / determining scale of the problem is customer support queries or customer feedback, site loading times, efficiency in terms of £££ saving eg. Man hours / days or software costs etc.

    Collaboration: Discussing value and priority options openly with your colleagues will help you deliver a product in a more confident and focused way, as it’s not easy making the big decisions on prioritisation because what’s at the top or moves to the top means that the items below won’t be done now or perhaps anytime soon, so checking and agreeing on the focus / roadmap helps to give confidence to just get on with delivering a high quality & value product without having to worry about justifying a decision you’ve made alone every minute of the day.

    Determination: Prioritisation changes frequently if you work in an agile environment, so being positive and determined to deliver upcoming projects you’ve been discussing for months or even years helps to keep focus on delivering the key business goals and provides reminders that it’s still on the agenda, no matter the level of incoming bombshells / distractions.

    If someone asks for something to be done urgently without providing any numbers representing the projected value or any element to give an idea of the scale of the problem you’re looking to solve, then asking why do it or what happens if we don’t do it in the next 12 months should help to quickly prompt the need to research more into the value.

    Projecting investment cost and taking time to dig into the real value the product change will make in a collaborative way, will ensure that you’re delivering frequent value to customers internally and externally in a happy, fun and relaxed environment.

    image

    I had the pleasure of catching up with Paul Silver who is Chief Strategy Officer at Media IQ the other month. From planning and buying across multiple accounts to diving into data to really help solve client problems and needs was part of the discussion.

    Having an extremely granular optimisation and well executed programmatic strategy helps identify those high performing segments, but it also highlights a challenge when it comes to predicting / forecasting the ROI for the individual segments / campaigns. Each segment is likely to have significantly different ARPUs and churn rates and you want to avoid pausing a campaign which is performing better than the channel average, but also stop campaigns which perform worse than the channel average (LTV is normally worked out on a channel basis).

    Media IQ have built predictive and forecasting models to help advertisers solve this problem plugging these models into campaigns run by Media IQ or just purchasing them off the shelf to use in-house. The models which update as campaigns mature would give optimisers insight into which segments are most likely going to yield a positive ROI for segments without having to do manual calculations each time across a huge set of ad campaigns / segments.

    With £billions being spent on advertising there’s also £billions wasted, so it’s good to get some scientific help to avoid this as much as possible but also ramp up ad spend in the most attractive areas.

    This is a good example of how the new age ad agencies / consultancies are helping advertisers solve their problems without just taking media spend and adding a high margin on top.

    You can of course build your own models but if you want to avoid the hassle then I’d recommend speaking to Media IQ.