Posts Tagged ‘Product’

Ownership

The product development lifecycle is complex, but in order for it to run like a well oiled machine there needs to be solid product ownership at the heart.

The below video explains Agile Product Ownership incredibly well and covers:

A typical Product Owner R&R would also be:

  • Market analysis
  • Competitor analysis
  • Customer analysis
  • Trends
  • Product line strategy
  • Product Vision
  • Product Roadmap
  • Backlog prioritisation
  • Epic / feature scoping
  • Epic breakdown to user stories
  • Requirement workshops and documenting them
  • User story definition
  • Detailed acceptance criteria
  • Backlog grooming
  • Sprint planning
  • Acceptance of user stories
  • Retrospectives
  • Daily stand-up

More info here on how to scale product when the time is right.

Scale

Once a product is mature and the product roadmap is filled up with valuable product iterations, it’s likely that the product owner and senior management will be keen to find out how some of the financial value driving product iterations can be delivered sooner.

Whilst having to balance technology improvements, technical debt, regulatory, security, bugs, dev ops and business requirements with only having one development team on the product stream would make this difficult, as there’s little room to work on multiple different types of work concurrently eg. business requirements concurrently with the more technical driven requirements.

To work on different sets of requirements concurrently, the product would need to scale which would involve adding additional product development teams to the product line. With more development teams working on the product would also require additional firepower from the technical architect and product owner role if delivery is to remain efficient and ROI positive.

An example of how you can scale the product owner role across multiple development teams who are working on the same product line:

Chief Product Owner (CPO)

  • Responsible for ensuring that the Product Owners are handling their product lines effectively
  • Handling the high level product strategy across all product lines

Product Owner (PO) / Senior Product Owner (SPO) of the Product Line

  • Market analysis
  • Competitor analysis
  • Customer analysis
  • Trends
  • Product line strategy
  • Product Vision
  • Product Roadmap
  • Backlog prioritisation
  • Epic / feature scoping
  • Backlog grooming
  • Sprint planning

Product Owner of the Development Teams (Associate Product Owner (APO))

  • Customer analysis
  • Epic breakdown
  • Requirement workshops
  • User story definition
  • Detailed acceptance criteria
  • Backlog grooming
  • Sprint planning
  • Acceptance of user stories
  • Retrospectives
  • Daily stand-up

The Associate Product Owner of the development teams could also be referred to as Feature Product Owner, Junior Product Owner, Product Executive or Business Analyst.

In order for the Product Owner to be able to focus on the product vision, prioritisation of the product backlog and product strategy to ensure the product remains competitive, it’s important that when adding additional development teams to the product that they get additional product owner support to help them out with the more tactical day to day activities, as you can see from the split in tasks above – Product Line Owner handling more strategic tasks especially prioritisation in all instances and the Associate Product Owner handles more tactical tasks.

Spreading a product owner too thin with little support could result in a lack of focus on both product strategy and getting product backlog items delivered in an efficient way.

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.

Done

Once the product backlog is in a good quality condition and the product backlog items (PBIs) start moving into development, there’s a significant amount of tasks to tick off before the feature can be marked as ‘done’ and therefore ready to ship.

Typically a development team would use a ‘definition of done’ (DoD) as a reference to ensure that none of the processes get missed off before it’s ‘done’, as each of those processes are essential and could have considerable consequences for the business and customers if it’s not done.

Some examples of what could be in a definition of done:

  • Code is reviewed by someone who didn’t do the PBI
  • Code is deployed to test environment
  • Feature is tested against acceptance criteria
  • Feature passes regression testing
  • Feature passes smoke test
  • Feature is documented
  • Feature has analytics tracking
  • Feature approved by UX designer / stakeholder
  • Feature approved by Product Owner

Missing any of the DoD processes before a feature gets delivered to a customer could result in critical bugs across the feature, causing bugs across other features in the code, bring down the product or delivering the wrong requirement, so it’s essential to take the definition of done seriously even if it means taking the PBI over to the next sprint resulting in potentially not meeting a sprint goal.

Invest

In order to avoid lots of panic and chaos the day before sprint planning because there’s no work in a ‘ready‘ state, it’s essential to have regular backlog grooming sessions which would result in having at least six weeks’ worth of high priority ‘ready’ work in the product backlog.

To get PBI’s (Product Backlog Items) in a ready state, it can take a lot of effort especially when it comes to chasing down dependencies or getting answers around the business requirements, but this is where the Scrum Master comes in to help out – although the Product Owner owns the product backlog, it’s the responsibility of the Scrum Master to help, guide and support the team to ensure they’re having frequent effective backlog grooming sessions, so there’s a good few weeks worth of ready PBI’s.

A new PBI is the start of a conversation and shouldn’t include solutions, so there should be ongoing questions around the requirements well in advance of the work going into development, until the development team feel they have enough information to size the PBI and then mark it as ready if there’s no dependencies.

It’s important to have a good quality product backlog (high priority items in a ready state) and frequently groom PBIs, to ensure the development teams are not only working on the highest priority items, but also that they’re working in an efficient way.

Some tips to getting a good quality product backlog:

  1. Create the user stories and prioritise in the backlog sooner rather than later – as a minimum the story needs to include ‘as a’, ‘I want’, ‘so that’ language with some high level acceptance criteria which will help start the conversation with the developers, giving them weeks to ask questions up front before it appears towards the top of the backlog.
  2. Making the problem / requirements clear with a stakeholder point of contact within the story for reference
  3. Having a clear title (summary) to the story, so you don’t have to open it up to find out what it’s about
  4. When there are questions from the developers to answer either by the Sub Product Owner (or Product Owner), stakeholders or technical, try to avoid leaving these unanswered for days – these should be responded to immediately as a priority
  5. For the ‘Feature Backlog‘ to be presented to the team monthly or bi-monthly, so they know clearly what the value of the relevant PBI’s are with some context around them
  6. Having flexible backlog grooming sessions – there’s no rule here, the teams can get together everyday if they like to groom the backlog until they’ve caught up
  7. Reinforcing to the development teams that they don’t need to know exactly what code to write and where in order to size the PBI, but instead the sizing should be based on a suitable solution making some assumptions
  8. Attaching customer flows / UX to the PBIs, with a link to ‘As Is’ and ‘To Be’ documentation

At least 10% of the teams time should be spent on grooming the product backlog and unless enough time is invested or they don’t get the support they need from the Scrum Master or Product Owner, then there’s risk of inefficiencies or the teams working on low priority PBI’s (Product Backlog Items) as the high priority items aren’t being groomed enough in time for sprint planning.

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!

Vision

It’s worth spending time coming up with a compelling vision statement, because it’s something which will be repeated over and over again as it’s the key driver to drum up excitement, passion, investment, confidence and trust that the product end goal is rather spectacular, solving the big problems and then in turn delivering huge value for the business and customers.

First things first, craft your vision statement which should only be one clear sentence, where in a nutshell it should explain what you’re looking to deliver, to who and why giving off a wow factor:

Vision statement

Then create a product vision board specifying who the target market is for your product, problems the product solves, clarifying what the product is and how the product is going to benefit the business and customers:

Vision board

Lastly, having a vision diagram is a great way of providing stakeholders and the business with a snapshot using one image of where you’re at with the product and where you’re heading. Having colour coding for ‘live’, ‘in progress’, ‘planned’ and ‘to do’ would cover it – there are plenty of mind map tools to help you visualise your product, one of which is Lucidchart which comes as a plugin for Confluence also. It’s important to keep the product diagram focused on high level features rather than detailed technical solutions around systems as that would be more of a technical architectural diagram:

Vision diagram

Having a solid product vision isn’t just to help the business allocate resource, but it’s also essential for the developers to know exactly where they need to head and why.

The Product Group London

If you’re a Product Owner or Product Manager and would like to participate in a variety of interesting product focused discussions, then The Product Group London is for you.

It’s also an opportunity to meet, interact and network with those in a similar role who solve similar problems and have similar challenges.

At the monthly meetups there’s normally a topic of the night and a featured product which gets discussed. For example, the July 2018 agenda was:

  1. Topic of the Night: Developing the role of product management – how do you develop the role of product management in organisations that either (1) have no formal product function, (2) have a product function that is not realising its potential, or (3) have a well-established function and need to develop it to the next level?
  2. Featured Product: Clear Review – Stuart Hearn, Founder & CEO

You can also:

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.

    With marketing departments typically focusing on P&L / ROI of ad campaigns and product development on product quality, product feature enhancements / performance and customer UX, it’s easy for the two business areas to be fragmented which could make the end goal harder to reach.

    Ironically although the individual department goals for both are normally so separate and different, the most common problems they face can sometimes be solved by the other eg. Acquisition marketing unable to increase incremental volume because the CPA / ROI / ARPU of the additional media spend doesn’t look healthy, yet fixing some bugs around the product feature in question, a feature enhancement or a new product release is likely to contribute to the solution that allows a raft of new customers through the door efficiently. Vice versa, a new shiny product or feature where the target audience is so niche that acquisition marketing efficiency / volume is poor or it’s unlikely existing customers will benefit, then it’ll be an uphill struggle to make the product viable.

    Fortunately the majority of brands have both of these areas in-house so it does make optimising the relationships and responsibilities easier. Naturally one area cannot exist without the other even when you look at brands like Google and Facebook who have groundbreaking products, yet still require nicely crafted ad campaigns to generate incremental revenue.

    Product developers don’t bite and marketers don’t just care about ad campaign performance, so close collaboration which is vital can be achieved by letting down a shield and discussing problems openly and bravely, so that multiple solutions can be discussed and you never know, the problem you thought was a tough problem to solve, may not be so tough anymore.

    Again, close collaboration is key and potentially another way of aiding / fast tracking an improved relationship is by recruiting a marketer or two into the product development arena or vice versa.

    The two departments working collaboratively to solve problems could lead to some spectacular chemistry.

    satisfied_customers

    No matter how much marketing you deliver, whether it’s billions of banners on the most premium sites in the world or you’re top of key generics consistently for Google, unless you have a stable product offering which customers genuinely embrace, then your brand has a fairly bleak future.

    Historically you could spend your way out of a crisis, but now if your site crashes often, you hide key T&Cs, mis-sell promotions, have a complex user journey, product not available on multiple devices, then in a few years time your brand value will show a clear decline which would eventually kill your business unless you adapt fast.

    I think the below video demonstrates the future in a fantastic way and how consumers will shape products, businesses and communication. The good thing about the future is that it will kill a lot of cow boys who are short sited and have no long term business strategy.