Header Ads

5 Product Management Hacks for Product Leaders [Mind the Product]


As a product leader, you are the product manager for a leadership team, and the tricks you learned in product teams remain valuable, they just need a little tweak. Here, to help you, are five product management tricks and tools for every product leader.

1. Value Proposition

A value proposition helps us to focus on users and to check that our product solves a real problem. It helps us to avoid falling in love with our product, requires research and promotes honesty. It’s the foundation of our product strategy.

Thousands of product managers have used the value proposition canvas tool from Strategyzer to help them refine their thinking and focus on the value proposition for their product.

It’s often up to product leaders to help an organisation stay connected with reality, so an honest, user-centred value proposition must remain the bedrock of our product strategy when we become product leaders.

While the outward image that an organisation projects needs to be positive and confident, organisations can forget that reality is more nuanced than their marketing would suggest. Myths that an organisation tells itself can act as a reality distortion field that masks failing products and poor return on investment. Using the rigour of a value proposition canvas to describe your organisation can help you to be honest with yourself:

As a Tech Startup

You’ve generated interest in your software. Investors have given you money. The press have written glowing profiles of your product. You’re high on life. But you’re yet to achieve a viable business model and user retention is terrible. A value proposition can help you to step away from the code and build empathy with your users. You may find that a gap in the market might not equal a market in the gap.

As a product leader you must create a safe space for your team
As a product leader you must create a safe space for your team

As a Digital Team in a Large Enterprise

You may describe yourself as leading the digital transformation of your organisation, bringing user-centred design to the products and services of your organisation, but you’re repeatedly asked to create websites or digitise paperwork. Creating a value proposition can help you to step outside your bubble and realise that you are just a small part of a much bigger organisation. Your colleagues may still see you as the IT crowd, fulfilling their requirements. There’s power in this knowledge, so own it. Use it to reframe the way your organisation sees you.

As product leaders, it’s often down to us to create a safe space for honesty about the value of our organisation. I’ve used the value proposition canvas to keep me honest many, many times.

2. Prioritisation Quadrant

A mature product has a lot going on at once. Prioritising the multiple classes of work required to keep a product live can be a headache for product managers. Barry Overeem’s prioritisation quadrant is a deceptively simple tool that can help.

I take three main principles from the prioritisation quadrant:

  1. Live products require new features, improved support, reduction in technical debt, and innovation.
  2. These four types of activity must happen simultaneously, throughout the life of the product.
  3. The proportion of our resources invested in each activity will vary over time. Sometimes we’ll spend a lot of our time on new features, other times it will be technical debt, and so on. We need to choose the amount we invest in each activity based on the long-term health of our product, not what’s most emotionally rewarding to do in the moment.

All of this is true at an organisational level – with a couple of tweaks. As a head of product, I have three responsibilities: the product strategy for my organisation; the performance of the product management profession; and collaborating on the learning and improvement of the organisation itself. This was daunting at first. But then I reminded myself that product leaders are just the product manager for a leadership team, and a mature organisation is like a mature product – there’s a lot going on. But a prioritisation tool might help. I took Barry’s prioritisation quadrant and adapted it slightly.

Organisational improvement

?%

Optimise current opportunities

?%

?%

Organisational debt

?%

Develop new opportunities

 

The most obvious quadrant is optimise current opportunities. This means investment in improving the value of our existing products and services through the activities listed in the original prioritisation quadrant.

The flipside of this is to develop new opportunities. This is space to learn more about our users, competitors, and new markets and territories. It’s new ways of doing what we do. But new is risky and it might take a while to get a return on our investment. But it’s important if we want to avoid our pipeline of opportunities drying up, and critical if we have ambitions for growth.

Working with agility requires a continual cycle of collaboration, delivery, reflection, and improvement. Organisational improvement is our space to do this. It represents an investment of time, money, and people to do this at an organisational level. For my money, this is what we mean when we talk about “agile at scale”. When we make space to look at our organisation and how it works we often see duplication. Duplication of the same work in progress is an opportunity for collaboration, while duplication of past work is an opportunity to share learning. We’ll often see queues too. This is an opportunity to reduce bottlenecks, simplify processes, and reprioritise work in progress.

Product leader holding a meeting
It’s vital to allow for a continual cycle of collaboration, delivery, reflection, and improvement

Sometimes things break. This is true of products and of organisations. This is organisational debt. An organisation might start with a small team that feels like a family and pride itself on its flat structure. Three years later after massive growth, that same organisation is now 200 people with significant pay discrepancies and a lack of clear career progression for people who’ve now been there for several years. Performance is dipping and HR cases are looming.

This is an example of organisational debt and should be seen as important work. It’s just as important as the work to improve your products, and you leave this work invisible and underfunded at your peril. Organisational debt is occupied by things that started life as opportunities for organisational improvement but were then ignored for weeks, months, maybe years. Then they prioritised themselves by becoming issues so serious that they require immediate attention.

A leadership team that has all these types of work visible on its roadmap and in its strategy is in a good place. And a product leader can help to make this happen.

3. Product Lifecycle

The product lifecycle, as shown below, helps us to shape our product strategy to fit the maturity of our product.

  • Research and development: Understand the needs of your users and build the minimum viable product needed to meet them.
  • Introduction: Test and refine your product with a small number of users, increasing resilience ahead of growth.
  • Growth: Get your product into the hands of as many users as possible, focusing on sales/marketing/support/communication/training/engagement.
  • Maturity: Reduce the intensity of investment, incrementally optimising your operational model and business model.
  • Retirement: If your value proposition gets weaker and your business model ceases to be viable. It’s time to end your product.

You can read the article – Exploit the Product Life Cycle from a 1965 edition of the Harvard Business Review that popularised the product lifecycle idea. And of course, there are plenty more recent articles at Mind the Product.

Organisations often have many products in different stages of their lifecycle. As product leaders, we need a way of prioritising at a portfolio-level. But this can be hard when the one metric that matters is likely to be different at each stage of the product lifecycle. So how do we prioritise products in development with mature products?

I’ve found McKinsey’s three horizons is helpful. My take on it is:

  • Horizon 1 is established opportunities, our mature products. It contains our best investment opportunities. Research has been carried out, large investment has been made, and we’re already seeing return on investment/benefits realisation. Investing in this space is likely to see return on investment within 12 months (so potentially within the same financial year as the investment is made)
  • Horizon 2 is emergent opportunities, our products in growth and introduction. This contains future opportunities that require significant levels of investment. Investing in this space remains pretty high risk but is crucial if we’re to continue to grow as an organisation. Investing in this space is likely to see return on investment within 12 to 36 months.
  • Horizons 3 is ideas in the research phase and development phase. This contains our riskiest investments, and our best chances to be transformational. Investing in this space is likely to see return on investment within 36 to 72 months.

We might consider managing our investments through these horizons:

  • Horizon 1 gets the bulk of investment, because it’s low risk and delivers an in-year return on investment. We might consider placing 70% of our investment here.
  • Horizon 2 might get 20% of our investment, because it’s medium risk and might not produce return on investment until the next financial year.
  • Horizon 3 might get 10% of our investment because it is high risk and will take several years to yield return on investment.

We don’t try and prioritise new products against mature products. Instead, we create investment pots for each horizon. We cap investment for each horizon. And prioritise like with like within each horizon.

4. User Stories

The first three tricks are strategic so let’s switch to something more tactical. The user story is the first point of contact with product management for many of us. Over time we learn that a user story is just one way of expressing a goal for teams. It’s not the only or the best way. In reality, our role as product managers is to set SMART goals for our team each sprint. We help our teams to aim towards sprint goals that are specific, measurable, achievable, realistic, and timely (SMART).

Set SMART goals
As product managers we need to set SMART goals for our team each sprint

Management and leadership teams are responsible for a wide variety of work, as shown in the prioritisation quadrant in trick 2 above. It’s easy to feel as though SMART goals don’t always work in this space, particularly when we try and recreate the user story format. But SMART goals are possible with the intangible work of “organisational improvement”. And it is possible to make them problem-focused.

I’ve lifted an idea straight from the Lean Enterprise book and used it over the last 12 months. The improvement opportunity template shown below helps to set SMART goals for intangible, leadership activity. If you bring something like this into your leadership team then you can help them to define and prioritise SMART goals just like a product team would define and prioritise user stories.

Improvement Opportunity

Background

Capture the critical information to understand the extent and importance of the problem. Tying the background to the goal statement reduces waste by limiting opportunities to focus on the wrong areas.

Current condition and problems statement

This is the problem the business stakeholder wants to address, in simple understandable terms and not as a lack-of-solution statement. For example, avoid statements like ‘Our problem is we need a Case Management System.’

Goal statement

How will we know that our efforts were successful at the end of implementation? Ideally, we will need one metric for success. For example, ‘Our goal is to reduce system failures compared to the previous test results of 22 major issues; our target is to reduce this by 20%.’

Root-cause analysis

Detail the hypothesis and assumptions, or a set of experiments performed to test for cause and effect.

Countermeasures

List the steps of an experiment to test the hypothesis.

Check/confirmation effect

Define a method for assessing if the countermeasures have had an effect.

Follow-up actions and report

Identify further steps and share what you have learned with your team or organisation.

5. Definition of Done

Definition of done is a useful tool for product managers. A good definition of done helps to ensure the quality of our work. A great definition of done measures the value of our work. It’s a space to ensure that we’ve genuinely created something valuable, rather than something shiny and new that never gets used.

When we move into product leadership space we’ll often hear a lot about ‘buy-in’ – from investors, other departments, and potential customers. How do we know when we have buy-in? How do we measure it? When is it done?

I enjoyed Janice Fraser’s model for measuring buy-in, shared at the 2018 Mind the Product conference in London.

Below is the UBAD model to think about whether you have buy-in (a buy-in diagnostic tool):

Decision Are they making decisions in support of it?
Advocacy Have you seen them speaking accurately, effectively, and supportively about it?
Belief Do they believe in it?
Understanding Do they understand it?

You need every level, in order, from bottom to top, in order to have ‘buy-in’. I’ve used this model several times in the last 12 months to help measure and set a definition of done for ‘buy-in’.

There you have it: five product management tricks you can totally hack as a product leader. Have you tweaked any product management tricks as you’ve moved into product leadership? Take the conversation online via Twitter using the #productleaders and tag @MindtheProduct. Or join the debate in the MtP Slack channel.

The post 5 Product Management Hacks for Product Leaders appeared first on Mind the Product.


Source: Mind the Product https://www.mindtheproduct.com/5-product-management-hacks-for-product-leaders/
Powered by Blogger.
// check for file exists steve added below // check for file exists steve added above