Posts Tagged ‘Business’

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 Owner 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 Owner
  • 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 Owner
  • Development Manager – monthly update on delivery efficiency improvements, development recruitment and strategy to deliver upcoming product iterations to be sent to peers, Product Owner, 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 Owner and head of department
  • Product Owner – 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 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.

    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.