Posts Tagged ‘Analysis’

Should analytics tracking be part of the DoD?

Posted: Oct 11, 2019 in Data, Product Management
Tags: , , , , , ,
0

Analytics

The short answer is yes – the product/team will 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 important to ensure that analytics/tracking is baked into the actual feature acceptance criteria/DoD, is so then:

  1. You can measure the value/outcome which the output had on the customer
  2. It doesn’t get forgotten
  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 up for success.

Gap analysis using ‘As Is’ and ‘To Be’ flows

Posted: Nov 19, 2018 in Data, Guides, Product Management
Tags: , , , , ,
1

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

How important is competitor analysis?

Posted: Jul 17, 2018 in Business, Data, Marketing, Product Management
Tags: , ,
0

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.

Identifying your KPIs

Posted: Sep 28, 2016 in Business, Data, Marketing, Product Management
Tags: , , , , ,
0

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.