Posts Tagged ‘KPI’

Strategy

VMOST = Vision, Missions, Objectives, Strategies and Tactics

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

VMOST example

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

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

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

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

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

Although the product owner is responsible for defining and owning the product VMOST, it’s important that it doesn’t happen in silo, as it takes collaboration with the rest of the business especially stakeholders/data/customers to help provide some guidance on the selection of problems to solve which would be represented on the VMOST.

Once the VMOST is ready, it’s time for the product owner to showcase this in a passionate way across the business and perhaps print it out on A0 to sit near the scrum team on the wall, so it can always be top of mind.

Good luck in creating your VMOST!!

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.