Archive for the ‘Data’ Category

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 fulfill their commitments they should be getting significant help, guidance and support from the Scrum Master or Team Lead, Product Owner 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 owner 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.