Blog – Product Focus World class product management training Thu, 13 Feb 2020 10:49:21 +0000 en-US hourly 1 Innovation – is it the product manager’s job? Tue, 28 Jan 2020 22:09:57 +0000 Part of the mission of many technology companies is to pursue innovation – it’s a great message to their customers, an enticement to new employees and a key tool to differentiate in crowded markets. But if it’s uncontrolled, there’s a risk of spending lots of money on expensive innovations, few of which pay back their investment.

So, what do we mean by innovation and how can we get it under control without stifling its opportunities?

The post Innovation – is it the product manager’s job? appeared first on Product Focus.

Part of the mission of many technology companies is to pursue innovation – it’s a great message to their customers, an enticement to new employees and a key tool to differentiate in crowded markets.

But if it’s uncontrolled, there’s a risk of spending lots of money on expensive innovations, few of which actually pay back their investment.

We came across one company with a mantra for innovation – a sacred belief that innovation was the answer to all their problems. Over 80% of their profit was generated by 10 of their 500 products. That’s a lot of innovation investment that’s been wasted!

It doesn’t matter whether you’re selling to businesses or consumers or if your clients are internal colleagues or governments – this challenge to deliver payback needs to be tackled.

What is innovation?

So, what do we mean by innovation and how can we get it under control without stifling its opportunities?

For many of us, the first thing that comes to mind when we think about innovation is famous examples such as, the iPod, iPhone, and iPad from Apple, the Uber business model, or Tesla with its driver-assist battery cars. These are examples of disruptive innovations that shook up people’s thinking about what was possible in a market.

Others might think of innovations that are being talked about but have yet to prove themselves such as 3D bioprinting, quantum computing, and brain-computer interfaces.

But not every innovation is so grandiose. Innovation in its broadest definition is about coming up with new and better ways of doing something. It could be as simple as a new feature or a new way of presenting something.

It’s the nature of most product people to want to be curious about their products, about what they can do to make it more valued by more customers, how they could improve the experience, or make it more profitable.

So, innovation should be part of our job.

Left to product people however, there’s a chance that innovation never happens because we’re so swamped by day-to-day issues.

Ensuring Innovation happens

So, how can we recognize the value of long-term thinking about innovation and not just the shorter-term tactical improvements?

One way that works is to consider targeting people on different time horizons.

To illustrate different stages of innovation, McKinsey developed it’s 3 horizons model. Its purpose is to ensure innovation happens.McKinsey’s 3 horizons model

  • Horizon 1 is about maintaining and defending the core business (they recommend around 70% of investment goes here)
  • Horizon 2 is about nurturing emerging business (around 20% of investment goes here)
  • Horizon 3 is about creating genuinely new business – these are your moon-shots, big risky exciting bets for the future (around 10% of investment goes here)

This model is typically applied at a company strategic level, but we believe it can also be used at a product level e.g., as a roadmap approach with Horizon 1 becoming “Now”, Horizon 2 “Next” and Horizon 3 “Future”.

An individual, or a single team, will struggle to span all horizons – the pressure to deliver wins in the short-term (in Horizon 1) means that Horizons 2 & 3 will get neglected.

So, it’s likely that Horizon 2 and Horizon 3 will be the responsibility of a different individual or perhaps a specialist ‘Innovation team’. It might even be a separate business run independently from the core business, so their thinking isn’t constrained by core business objectives, timelines, and governance. In bigger companies, this team may also be tasked with looking for companies to acquire who already have market experience or products in the area of interest.

If the business isn’t big enough to justify a separate team, then it might be that a product person works on Horizon 1 most of their time but has 1 or 2 days a week focused on one of the longer-term horizons.

Balancing investment across the timelines ensures that innovation happens in a company.

How do we get individual product people to take innovation seriously? By enabling their creativity and setting personal objectives that require forward-thinking. You might, for example, require them to present every quarter on their view of future opportunities and options.

Turning innovation into product

It would be great to think every innovation is a winner. The reality is that even those innovations that some customers value don’t always scale well – the prototype (or idea) may prove itself, but can it be delivered at a profit for many customers and not just those initial enthusiasts?

There are several stages that any great idea will go through on its journey to becoming a great product:

  1. Discovery: Exploring the market to find the idea – the customer problem worth solving and matching this with a solution that works
  2. Validation: Building the initial prototype and testing for product-market fit to validate it works and get market feedback
  3. Productizing: Defining and standardizing what’s built and how it’s sold, ordered, delivered and supported so it can be delivered reliably at scale (i.e., it’s productized)
  4. In-life evolution: Evolving the solution to grow market share, revenue, and profit (or whichever combination makes sense for the maturity of the product and for the business – see more below)
  5. In-life cost management: Reducing ongoing year on year costs so deliveries are profitable (and still valued by customers).

For many product people, stages 1 and 2 are the exciting activities – holding focus groups with customers and internal colleagues on where future challenges and opportunities lie is a fun thing to do. Knocking up prototypes, maybe in a Google Sprint, to validate our riskiest assumptions about an idea gives everyone a buzz.

But stages 3, 4 and 5, when products are created and optimized, are the activities where product people earn their salaries. These are the activities that deliver profitable revenue to the organization.

We’re not saying that 1 and 2 aren’t important but without 3, 4 and 5 time and money invested in creating and validating ideas are wasted.

The deliverable output of stage 2, product validation, might be a Minimum Viable Product. We’ve talked about challenges with MVPs in other blogs so we won’t repeat the challenges here.

These stages are very similar to the steps a start-up typically goes through to get to a sustainable business model. If you haven’t read it take a look at The Lean Start-up by Eric Riess.


Product innovation, regardless of whether it delivers major new ideas or minor enhancements, is a key activity for any business looking to differentiate itself.

It’s part of the job of everyone in product management.

So, keep curious to identify what you can do to help customers do the things they value. And if you manage a team, task your people to come up with a forward-looking view for their product domain.

Andrew Dickenson
Product Focus Founding Director

The post Innovation – is it the product manager’s job? appeared first on Product Focus.

]]> 0
There is no spoon: Accountability in a matrix environment Mon, 30 Dec 2019 15:11:38 +0000 Changing from traditional ‘top-down’ models of management to a more matrix approach can be a challenge. How can you be sure you are empowering your teams, while also keeping the right level of accountability and governance? In this blog we look at some ways to ensure you unlock the potential of matrix management.

The post There is no spoon: Accountability in a matrix environment appeared first on Product Focus.

In the beginning, was the Boss

It’s hard to believe, but in the olden days, before self-organizing teams and servant-leaders, everyone had a boss. Organizations were managed vertically, with teams in strict hierarchies. Bosses told you what to do, how to do it and when to do it. If you didn’t do it fast or well enough, your boss would discipline or perhaps fire you.

Management by diktat doesn’t generally lead to desirable outcomes, so many organizations spend time analyzing strategy, breaking it down into progressively smaller tasks that can be ‘cascaded’ to underlings (to use the jargon). Everyone is given objectives that measurably contribute to the overall strategy. At each level, individuals are accountable for all the activities of those that report directly or indirectly to them.


A vertical management structure.

Figure 1: A vertical management structure. Even in a small company, there usually emerge levels of management: board, strategic, operational and team leadership. Delivery teams have little opportunity to take ownership.

While this approach gives context to objectives, they are still instructions from above. This works well when people are collaborating on a highly planned project, such as conducting brain surgery, building a pharaoh’s pyramid or invading a small country. And, if you want to be able to concentrate blame on an individual so you can fire them when things go wrong, it’s perfect!

In creative endeavors (e.g. making software), this doesn’t work well because whipping rarely improves the performance of people whose motivation is to make great stuff. If you manage people with a diverse range of skills, as in a typical product team, it’s also challenging to understand and assess performance, thus harder to coach them.

Furthermore, there is little opportunity for people at the lower reaches of the hierarchy to challenge assumptions made several levels above them. There may be continuous improvement processes (e.g. Kaizen) in place, but they’re designed to remove waste and blockages, rather than to enable delivery teams to take ownership on a day-to-day basis.

We need to talk about Erica

Erica worked at Fox Lab technology, an agency that built bespoke business software. A capable engineer who enjoyed working in a team, Erica wasn’t a clock-watcher, but neither would she throw herself onto a pyre for the company. Fox Lab had a vertical management hierarchy, and Erica found the managers to be affable, albeit usually quite stressed. The directors were distant and, despite working there for two years, she’d never spoken to the CEO, Carole.

Working at Fox Lab was a series of broken deadlines. Instructions were passed down without context or rationale. Erica’s manager, Martin, would tell her to work on this, then drop it to work on that, these pivots often occurring immediately after he’d been in one of those shouty management meetings. Martin had a cordial relationship with his team but often had an exasperated tone, scarcely concealing his frustration. He had risen to his position through dint of excellence as an engineer, but a few years in management’s blame zone had left him tight-lipped and resigned.

Morale was rock-bottom, and the only thing keeping people at Fox Lab was their generous salaries – “blood money” they termed it. You would never have guessed this from its external messaging. It worked very hard on PR and, despite its hollow soul, it occupied a strong position in the market. Clients were frequently rankled by its serial failure to keep promises, but one of its execs was an expert spin doctor who always managed to schmooze them. This usually meant making more unsafe promises based on assumptions that hadn’t been sense-checked with the delivery team.

In truth, Fox Lab was a ‘zombie’ company – unaware that it was already dead, and only a few customer desertions away from a rapid demise. Carole the CEO never let her team know about her sleepless nights due to constant anxiety… why couldn’t she seem to get things turned around? Why were they always on the back foot, continually missing deadlines and disappointing clients, despite her efforts to realign expectations? She sought and gained assurances from her directors, but time and again, these proved worthless. She avoided blame culture, but nobody ever seemed to be accountable and she wondered why nobody had been disciplined, let alone fired! It was always just excuses – different excuses every time but always rooted in someone claiming they hadn’t been informed, something had been oversold or someone had been promised resources that hadn’t been forthcoming.

How did it come to this?

In Fox Lab’s early days, everyone knew what everyone else was doing, and they mucked in to help each other. As the company grew, it became necessary to appoint managers to support and keep tabs on people. Carole increasingly found herself spending time with large clients, persuading them to invest more in, rather than ditch Fox Lab’s services. She promoted some managers to directors so they could manage the company day-to-day. They, in turn, promoted the more trustworthy amongst their teams to manage the teams on their behalf while they strategized.

Every now and again it would become obvious that there were too many chiefs and not enough Indians, or that a particular department had grown too large or small, and a restructure would ensue. Directors would do some more shouty meetings, boxes and arrows would be drawn, and announcements made. The teams would sigh, spend a few months getting used to the new arrangements (or quit), then carry on carrying on. They were used to these false dawns, with the periodic arrival and inevitable departure of heroes who were going to fix everything with their new way of doing things.

In all this continual strategic realignment and hardening of management attitude, nobody had considered what Erica could do to help. Sure, her manager had assessed her engineering abilities, and she had been given appropriate KPIs and targets to reach, but the only thing Erica had control over was lines of code. She had read about the Hoshin Kanri management philosophy employed at Toyota and considered her profession to be Genchi Genbutsu (the stuff that really matters). Depressingly, however, she spent her days making things that nobody would ever use, driven as they were by corporate angst rather than real customer need. She was well paid, but she longed to be able to express herself and go home feeling good every day. Once she’d saved enough for a mortgage deposit, you wouldn’t see her for dust…

Sh*t rolls downhill

Fox Lab’s problems are caused by its top-down management philosophy, in which teams are given commands with deadlines. Carole isn’t a bully, but like many CEOs and founders, she is driven and multi-skilled and had grown accustomed to making calls without challenge. She didn’t deliberately set up a pyramid of control, it just happened by default. Even in modern businesses, most people want someone else to make decisions for them. As is generally the case for a social species, this tends to create control structures with a ‘pecking order’, in which the most assertive rise to positions of power.

This is fine when you’re a small team, but as the business grows, even the most energetic and curious manager cannot track and understand everything happening under their watch. The result is that when things go wrong – which happens in any creative industry – managers struggle to identify or address the causes of failure. They’re held accountable for something they cannot actually control, and their only recourse is to apply more pressure downwards whilst massaging information flow upwards. This ‘boss problem’ can lead to a toxic macho culture with bullying, cover-ups, and even corruption. So, if the vertical command doesn’t work, what do you do?

Enter the Matrix

In the 1970s, Matrix Management emerged in response to the increasing complexity in global businesses, which brought conflicting demands from product, functional and geographic divisions. It provided the flexibility required to keep up with the accelerating pace of business change and competition and combatted oversimplification, silos, and parochialism within the business. The concept introduced a multi-dimensional accountability structure, with both vertical and horizontal accountability, easing the deployment of people to new initiatives. Project output was separated from personal development, and everybody had two ‘bosses’ – your line manager who would look after your welfare, performance and professional development, and a ‘dotted line’ report to your project manager who would direct your project-specific activities.


Matrix Management 1.0

Figure 2: Matrix Management 1.0: Functional performance and project output are separated, but the Project Manager is still a quasi-boss who ‘pushes’ work onto the team. Approval from line managers may also be required (known as ‘soft’ matrix).

This is termed ‘horizontal management’ due to its cross-organizational way of working, recruiting staff onto projects from vertical functional units. The project manager’s decision-making power varies – in ‘hard’ implementations, they rule supreme; whereas in ‘soft,’ they depend upon departmental heads for authority. Larger organizations may further increase flexibility by creating a ‘bench’ system, in which staff who aren’t currently employed on projects wait for a suitable project to come along. They may be deployed to projects or apply to work on them voluntarily.

Most of us work in matrix environments, officially or otherwise. It’s rare for an organization, especially in the technology industry, to operate purely on a hierarchical basis. Capable and proactive people don’t thrive when confined by artificial boundaries and tend to be ‘lent’ to other teams or help them out voluntarily. If this ‘horizontal pressure’ isn’t released it leads to frustration amongst high performers – quality will out, and if you don’t let talented people express themselves, then they will find somewhere else that will. An indicator of this problem is serial restructuring, in which the company keeps reorganizing its teams to enable the right people to work on the right things, resulting in loss of momentum and confidence in management. Organizations like this don’t know they’re in the matrix, but they can tell there’s something wrong with the world.


Take the blue pill ...

Figure 3: Even when an organization has a vertical management structure, people with in-demand skills tend to be utilized across departmental boundaries, in effect creating an unofficial matrix.

I’ve worked in the software industry for over two decades, and in most of the roles: development, support, consultancy, operations, pre-sales, sales, marketing, management, and strategy. In all that time, I’ve rarely met anyone who thought that matrix management was easy, and many that thought it can’t work. Critics cite a lack of accountability, priority conflicts, the difficulty of reporting and even people gaming the system. In one case I knew of, someone ‘working’ at a large systems integrator spent eighteen months on the bench, on full pay, before he was finally rumbled!

How to entirely miss the point of matrix

Trying to fix the boss problem by giving everyone another boss isn’t likely to succeed. It causes ambiguity of purpose and accountability. How do I prioritize? How can I be held accountable for something I can’t control? Who evaluates performance? What is performance if it’s not doing what you’re told to do? Faced with conflicting pressures, people will tend to align with a tribe in a turf war, playing bosses off against each other and descending into a perpetual cycle of blame/excuses or even just simply giving up. Warning signals include conflicting communications, a proliferation of meetings and reports. Trust and accountability break down, leading to high stress, absence, and churn.

Just as overlaps are created, so too are voids into which proactive people naturally jump, without a mandate or clear accountability. They end up over-reaching, causing as much trouble as they solve, creating tensions in teams and burning themselves out. Other high performers are tactically shuffled between projects, with a consequent drop in productivity due to spin-up time and disruption caused to established teams. Top-down has been replaced by a pincer movement, top-down and from the flank.

Unfortunately, there’s no shortcut to a culture of empowerment and accountability, as put by Christopher A. Bartlett and Sumantra Ghoshal in the Harvard Business Review (July/August 1990):

“…companies that fell into the organizational trap assumed that changing their formal structure (anatomy) would force changes in interpersonal relationships and decision processes (physiology), which in turn would reshape the individual attitudes and actions of managers (psychology). But as many companies have discovered, reconfiguring the formal structure is a blunt and sometimes brutal instrument of change.”

Customer value is determined by customers, not bosses

To be accountable for something, one must be able to influence its outcome. Even in pull systems like Scrum, where the delivery team chooses what to deliver in each timeframe, if they’re doing so under pressure from a boss, then it’s unlikely they’re being driven by customer value. They will constantly be trying to speed up the things the boss wants to be done. Even if that boss is a Product Manager who has good data or a knack for spotting customer value, the intellectual and emotional constraints they place on the team will distort their behavior. Moreover, the team cannot be truly accountable for their output, because they never had any choice about what they did. This leads to learned helplessness, manifested as ‘cargo cult’ or ‘death march’ projects.

To enable the team to perform to their potential, they should be seen as a microcosm of the company, embodying the corporate culture and focus on customer value – your company has that, right? Much has been made of the role of Product Manager as representing the voice of the customer but consider how effective it can be if they truly are the customer of the delivery team. By implementing an internal economy in which horizontal relationships are based on customer-supplier relationships rather than executive control, you can focus people’s attention on their responsibilities to each other rather than what they’ve been told to do by an individual.


Internal economy

Figure 4: Implementing an internal economy can remove the ‘boss’ problem, leading teams to focus on customer value. Team members cannot use the ‘just following orders’ excuse.

Performance is agreed and enabled, not forced

A criticism of matrix is that it requires really capable people; I’d say it’s the only way you can attract and retain those people and build a culture of high performance. Talent won’t tolerate decision paralysis, a sort of ‘corporate yips’ caused by a chronic lack of strategy and/or management information. They just want to get on with the job, and the internal economy places trust in all team members to make the right decisions.

“The reorganizations that work best don’t just reshuffle the boxes and lines on an org chart. Rather they improve a company’s ability to handle its most important decisions. They enable people in the organization to make better decisions. They speed up decision making. They also increase the ‘yield’, or the proportion of decisions that are executed effectively.”
– Decide and Deliver, Bain and Company 2010

Traditional team architecture is defined by bosses, job descriptions and KPIs. There may also be a RACI, er, matrix detailing everything for which you are Responsible or Accountable, or to be Consulted or Informed. However, RACI often incentivizes people to do anything other than creating value (see Goodhart’s Law, or “Whatever you measure, that’s what you get”). It also doesn’t answer the question “What needs to change?” Simply saying that an engineer is “responsible” for the launch of a product doesn’t help much – arguably the office cleaner is also in some way responsible. RACI is useful only for singling someone out to blame.

To meaningfully track a role’s performance and development, it’s necessary not only to define what is to be done but why and for whom. Just as any product has its target market and value proposition, so it’s vital to focus on the value that each role offers. This need not require a full product strategy – imagine trying to run a business in which every role was itself a business – but focusing on outcomes will ensure that people aim to deliver value and can be managed by exception. One way of defining this is in a simple, um, matrix:


A simple matrix

Figure 5: Accountability isn’t a simple, easily measured metric because people’s contribution to projects is complex. Caveat: this example is not intended to define how to do product management or Scrum 🙂


At first glance, this may look complicated, but it’s no more so than writing someone’s job description with structure and context. The term “KPI” (there I said it) has become something of a swear-word in the tech world, perhaps unfairly – there’s nothing wrong with measuring things, the mistake is to measure the wrong things or with a lack of precision. In a matrix economy, defining success metrics for each ‘deliverable’ from each role to each other takes the form of a contract between those roles; these contracts can be negotiated by the team so that nobody can complain that unfair requirements have been pushed onto them.

For example, traditionally, you might specify that an engineer should “write code using Javascript” and put them through exams. This will certainly measure their coding skills but won’t tell you anything about their ability to work in a team, focus on outcomes or take accountability. Instead, you could require that they “create product increments” with the acceptance criteria being that they are stable, secure, performant and written in Javascript, with performance metrics agreed by the team.

Embracing the matrix economy

It is not a simple or easy journey to move from top-down, vertical command-and-control to the matrix economy model, with its focus on outcomes rather than compliance, its requirement for a high degree of trust and the shift from management to coaching. The whole organization needs to buy in, starting at the top, and it will take time to make the transition.

The job of the line manager will no longer be to tell the team what to do, but to coach them, ensuring that they are equipped to succeed and insisting that they give it their best. The traditional concept of a Project Manager that directs everything about the project doesn’t fit well into this model, because the ‘customer’ of the team should be concerned only with the outcomes from the product development and not how it was done. Thus, Product Managers focused on customer value, are needed instead. I’d define a maturity model but as Product Focus produces their own, I’ll point you to that one instead.

Negotiating between individuals, teams, and functions in this way leave no place to hide when it comes to accountability. The performance or procedural issues, within and between teams, can be identified unambiguously because they’re reckoned against specific and measurable duties. These, in turn, drive customer value and thereby business success. Time to take the red pill.

Aidan Dunphy
Product Focus Senior Consultant

The post There is no spoon: Accountability in a matrix environment appeared first on Product Focus.

]]> 0
Tools Overload and Exhaustion Mon, 25 Nov 2019 11:18:15 +0000 Product Managers are increasingly becoming overwhelmed by the number of tools they interact with daily.

We look at some of the main culprits - tools for communication - and discuss some ways to help.

The post Tools Overload and Exhaustion appeared first on Product Focus.

On our training courses, when the topic of tools is brought up, it’s often met with a collective groan from delegates.

Tools are designed to make our lives easier, so why does the topic frequently get such an adverse reaction?

Well, the answer would seem to lie not in the ‘usefulness’ of the tools but in the sheer number that product managers can be required to interact with every day.

Drowning in tools

That’s why people tell us;

“We’ve got too many tools! Everybody uses their favorite tool, and if you want to work with them, you need to learn it.”

“It’s a nightmare keeping on top of all the comms I need to use – email, multiple slack channels, multiple WhatsApp groups, text, voicemails. Then there are the notifications that come along all the time from tools like Jira.”


“The highest cost for most tools is the time it takes you to learn how to use it!”

It would appear, then, that some of us in product management are suffering from a state of tool exhaustion – an overload of tools that, rather than making our jobs easier, consume our valuable time and create frustration.

What should the benefits of tools be?

The word ‘tools’ can mean many things: a business case spreadsheet template, a generic office application like powerpoint, your laptop, or a pen. Most of the frustration is aimed at software-based tools used to help when working with products.

We know the benefits these product management tools can bring are significant.

If implemented correctly (with well-designed governance around their use), product management tools can improve efficiency in a company. Benefits include a single source of truth for things like product roadmaps and storing requirements as well as more effective working practices for teams spread across multiple locations.

See our Top 10 Product Management Tools Report.

What goes wrong?

These tools generally work well when everyone uses them consistently. What seems to happen in many organizations is that a particular tool is introduced by one area because someone worked with it in a previous job or reads the website blurb and thinks great – that’s what we need.

But then sometime later another team introduces a new tool – the ‘latest greatest thing’ and start uses that. It’s fine for this team who use it regularly and develop an understanding and agreement on how to get the best from it. Where things go wrong is when other teams need to use it too, or data needs transferring from one tool to another.

Unfortunately, as product managers, we often experience these challenges because we work with so many different teams across the business.


Touchpoints diagram

Product management has many touchpoints across a business.

And learning how to use these tools can take some effort – especially if you’re not going to be a regular user.

Have you ever tried to log-in to a new tool or portal e.g., Salesforce, to find some information? It takes time to learn to find what you want (or pulling in favours from an expert). Then, if it’s a couple of months later when you need to do it again, you have to go through the whole frustrating process one more time.

The main culprits – tools for communication

As we have seen, product managers operate across many business areas, with stakeholders across the organization. Often, each team will have their preferred method of communication or channel to monitor for feedback and questions.

Overload isn’t just limited to product management; more widely, the nature of business communication is changing. Whereas, years ago, the primary method of communication would be a call or a face-to-face meeting; our ‘always online’ culture has led to a rise in so-called ‘reactive comms’.

If you are giving feedback by a call or face-to-face, you will often prepare what you are going to talk about in advance. You will be mindful of the time it takes out of your day to take part in such a call, so you plan your thoughts to make effective use of that time. Any potential misunderstandings can also be ironed out through the course of the conversation.

However, now that it takes just a few seconds to fire-off thoughts in a Slack message, it can be easy to go with our initial reaction to something and hit send. This often results in a long series of back-and-forth messages, which ends up taking longer than a five-minute conversation on the same topic.

Reactive comms have created behaviors that remove the ‘self-editing process’ that would typically take place before a meeting or a call. There is little time for reflection. They have also become a crutch if we need a question answered. Rather than try and find out the answer, or wait until the next meeting with the appropriate person, the natural reaction is to send the person a message immediately.

Communications overload

Research shows that communication overload is a significant source of productivity loss. In this study by software company RescueTime, their analysis of 50,000 workers showed that, on average, workers checked their emails and messages every 6 minutes, and 40% never managed more than 30 minutes at a time of uninterrupted, focused work.

While it may just take a few seconds to check a slack message, it dramatically affects the amounts of ‘deep work’ that we can get done. People, by their nature, are not good at multitasking. So even the slightest disruption during a period of focused work can take, on average, 9 minutes to get back into the mind frame of deep, concentrated work. Some studies (like this one from the University of California Irving) have it at over 20 minutes to refocus! Whatever figure is closer to the truth, we can see the significant impact that constant interruptions can have.

What can you do?

As we advised in our blog on breaking the cycle of firefighting, there is no requirement always to be available to answer any question that comes your way. Breaking the cycle of reactive communication by setting clear expectations and boundaries will drive positive behavior.

If your stakeholders know that you don’t respond immediately to their ‘quick question…’ on messaging apps, then those messages will soon stop. People will either solve issues themselves, find a more appropriate place to get the answer or find a more appropriate time to ask you. A good way to implement this is to block time out of your diary when you need to focus on ‘deep work.’

Another way to minimize the number of reactive communications you receive is to hold regular meetings with business areas (if you don’t already do this). Sometimes, just having that date in someone’s diary will get them to hold off on those ad-hoc requests they would otherwise send through email or WhatsApp.


Unfortunately, dealing with a growing number of tools is a fact of life for many product managers. However, our central position in the business puts product management in an ideal place to recommend standardizing the tools used with products.

When it comes to communications tools, it’s never going to be feasible to completely ‘go-dark’ in this digital world. But, finding a better balance around your communications and when to interact with your various comms tools can have a hugely positive effect on your time, productivity, and even general outlook to your job.

So how do you manage to avoid tools overload and exhaustion?

Any advice to share?

Ian Lunn
Product Focus Founding Director

The post Tools Overload and Exhaustion appeared first on Product Focus.

]]> 0
Product Management and the Impostor Syndrome Fri, 25 Oct 2019 10:46:27 +0000 Many workers, across all industries, know what it’s like to feel like an impostor in their own job. It’s a feeling that’s especially prevalent in product management.

We look at the reasons why Product Managers are at risk from Impostor Syndrome and some ways in which they can combat it.

The post Product Management and the Impostor Syndrome appeared first on Product Focus.

The first morning of our training course involves many discussions and exercises on the role of product management. In one of these rounds of discussions, I confided that, especially in the first few years, I often felt like an impostor in my job and on the verge of losing control.

Heavy nodding in the room confirmed a shared view.

During the break, participants told me how good it was not to be alone in this feeling of self-doubt.

Though this feeling is not reserved exclusively for product managers, it became increasingly clear to me over subsequent training courses that this is a common occurrence among product people.

This feeling is known as ‘impostor syndrome’.

What is impostor syndrome?

With this phenomenon, those affected cannot internalize their success and attribute it to external circumstances (“I’m just lucky”). They see praise as an overestimation of their abilities (“Oh, everyone could have done that”). On the other hand, failures, difficulties and slow progress are attributed mainly to their inadequacy (“I just can’t do it – others would”).

This results in a latent feeling of ‘winging it,’ not being able to accept one’s own real successes and thinking that you will probably soon get found out – a constant spiral of self-doubt.

Why does it seem to occur so frequently in product management?

Some people are good with the approach “Fake it, ‘til you make it” – but in product management, there seem to be factors that make this challenging. So, why does impostor syndrome seem so common in product managers?

We have identified the following reasons as possible causes:

The expectations placed on product managers

Product management is an important interface between company strategy, development, customers, sales, and many other stakeholders. Product managers typically work with (and are the interface between) many different areas as shown in the diagrams below.


Touchpoints diagram


As such, a huge amount of expectation is built up. We’re expected to be experts on the product, with answers to every technical question, and experts on the market, reciting the needs of customers in our sleep. We must carry the company with us through our product vision, but also face the harsh reality of product defects, strong competition, and customer complaints – solving problems and sorting things out along the way.

Important decisions need making, but they need to be right. After all, we’re sitting at the crossroads of all the key information. We must be convincing and empathetic, assertive and understanding, goal-oriented and realistic. When it comes to the product, product management must always be ready.

Often, an unclear role definition means that we feel responsible for everything concerning the product. If we’re new and want to impress, we feel we have to fulfill all our colleagues’ expectations. We risk trying to become everything to everyone.

The rest of the company is happy that there is someone who takes on this role. Any product problem they have can be off-loaded to the product manager. Product management becomes the caretaker department, the janitor for cleaning up the messes, and there is less and less time to set up the product for long-term success – after all, something else is always more urgent. These situations lead to a lack of strategic planning which stores up problems down the line.

And, it can feel good in the short term – the quick satisfaction of having fixed yet another problem. However in the long run, it means we disappoint ourselves and others, again and again, as we fail to live up to our and our colleagues inflated expectations … and the impostor syndrome creeps in.

Dozens of views on what product managers actually do

There are numerous forms of product management, and it varies according to industry, company size, reporting line in the company, and interpretation of our role by management and other departments. It’s quite clear what a salesperson does, a buyer does, and what a financial controller does. For product managers, the boundaries, in most companies, between our role and the teams with which we interface are much more fluid. After all, it’s about our product so we want to step into any gaps to make sure it’s successful! It is also not helpful that some managers actively define product management as the point of contact for everything to do with the product.

The fact that product management is learned ‘on the job’ can lead to uncertainty as to what one’s role is and how to do things right. Success does not feel sustainable – problems dumped on product management that are not solved promptly are viewed as product management’s fault.

These are prime conditions for impostor syndrome to emerge.

Product management means constantly learning

There is no industry-wide standard qualification for product management. Many of us have previously worked in other areas, such as technical planning, Development or Sales. Our knowledge and skills in these areas, combined with a great passion for the products led us to become product managers. But in product management, we have learned that our current knowledge is not enough and that we must always keep an eye on changing technologies, customers, market movements and trends.

We had to learn to swim free, learn the role, recognize and close our knowledge gaps – again and again.

This attitude of willingness to learn is good and important, but at the same time, we are often working at the limits (and beyond) of what we know. We are, therefore, not only exposed to inadequacies more frequently but, by pushing into areas where we’re not the expert, we also actively make ourselves more aware of them.

Too little time to internalize success

Typically, there are very few days in which we can avoid the hustle and bustle of daily events. The market is moving rapidly, and it is a real challenge not to lose touch with customers and competitors. And, if that wasn’t enough, we must then develop our skills and learn new methods of market analysis, product development or digital marketing.

In between, there is little time to accept and record our successes; the fantastic customer feedback, praise from your colleague or successful quarterly results go unacknowledged – after all, these successes involved many people. Failures, unsolved problems, and complaints, on the other hand, feel more like a symptom of one’s inadequacy and resonate longer.

So, what can product managers do to avoid impostor syndrome?

Awareness of the problem: We must be aware that this syndrome exists and that we are exposing ourselves to many things that can bring it to the fore. This realization is the first step towards being able to tackle it effectively.

A clearer definition of the role: There is a saying in product management that job descriptions are usually out of date six months after taking the job. Additionally, companies are very good at defining what product management is responsible for but find it difficult to define all the product activities where product management delegates tasks to other areas. This leads to us taking a kind of ‘super-responsibility,’ while losing track of who else can execute product-related activities in the company.

A clear definition of the role and responsibilities can help here. The Product Activities Framework is a useful tool for discussing one’s role with managers and for defining which activities to delegate.

Product activities Framework

In our blog article on ‘Firefighting,’ we discuss some different approaches, such as the 5 Why’s, to escape from the firefighting mindset and concentrate on the more important tasks.

Learning and showing self-confidence in one’s abilities: Even if there are difficult days when all our efforts don’t lead to anything, we must become aware of our abilities. Recognizing and working on the gaps in our knowledge is an enormously important skill for product people. This helps generate insights that many others would not get.

At the same time, we should not take our abilities for granted, even if they seem completely normal to us now. It can help to write down a list of our strengths with the help of someone we trust and use them when the need arises to build our self-confidence.

No false modesty: We must learn to acknowledge our successes and “blow our own trumpet.” A smart way in which product managers can draw attention to their own successes, without praising themselves directly, is to send ‘thank you’ e-mails to project participants (e.g., the launch team or a sales team), selected managers, and colleagues. This shows gratitude while reflecting success on oneself.

A culture where experiments and mistakes are allowed: Product discovery and product marketing require us to be ready and willing to experiment – the first idea is seldom the best one. Agile software development and agile marketing allow us to experiment and find the most successful approach through quick idea generation, small iterations, tests, and new approaches. However, this also requires a culture in which this iterative discovery approach sees failures as a learning opportunity and allows enough time to do it.

Companies that have introduced agile development approaches like Scrum know what a change it is, and how difficult it is to break out of familiar patterns (e.g., not being able to write down all the specifications at the beginning of development).

We can help raise awareness of approaches, such as product discovery and experimentation in digital marketing, by demonstrating the benefits of these approaches (faster response to new requirements, better use of capacity, higher success rate).

Awareness that product management isn’t a race, but a journey: Even successful product managers admit to being regularly plagued by self-doubt. Shouldn’t they be happy about their obvious successes and realize that they have reached the top of the ladder of success?

Those who have learned to deal with these self-doubts often say that they have made themselves aware that there is no “arriving.” Product management is not a ladder, but rather a never-ending journey on which one always encounters new and exciting challenges.

In conclusion

I would go so far as to say that product managers who have not noticed this kind of self-doubt are probably doing something wrong! If impostor syndrome is a result of branching into areas you have yet to explore, not experiencing some self-doubt may be a result of remaining in your comfort zone. Product managers must retain their curiosity and embrace the aspiration of ‘lifelong learning.’ I believe imposter syndrome is just one side effect of our path to becoming better product managers.

Jan Harste
Product Management Coach and Product Focus Consultant, Germany

The post Product Management and the Impostor Syndrome appeared first on Product Focus.

]]> 3
DevOps 101 for Product Management – how it can empower you! Thu, 03 Oct 2019 08:36:16 +0000 Many of you may have heard the word DevOps come up over the past few years. If so, you may have wondered what it involves and, more specifically, what it means for product management.

In this blog, we examine what exactly DevOps is and what it means for Product Managers.

The post DevOps 101 for Product Management – how it can empower you! appeared first on Product Focus.


Many of you may have heard the word DevOps come up over the past few years. If so, you may have wondered what it involves and, more specifically, what it means for product management.

In this blog, we’ll examine what exactly DevOps is and what effects it has on product management models. I want to thank the team from DevOpsGroup for collaborating with us on this post and for helping me get ‘under the skin’ of what DevOps really means.

With many online products moving to a service model, DevOps has become an increasingly growing trend in companies that have software as a service (SaaS) products. While it seems that DevOps is a relatively new trend, it has been around for ten years. Started by members of both the development and operations functions, DevOps grew online through development forums and groups. In 2009, the first DevOpsDays conference was held in Ghent, Belgium, bringing the movement to a wider audience.

Coinciding with growth in Agile development practices has meant that DevOps models are now more accessible to a broader range of companies.

What is DevOps?

So, what is DevOps? Well, much like product management, it can vary from company to company and product to product. DevOps is hard to define as it also changes depending on the company and its products/services. At its most basic, DevOps is about bringing together the people, processes, and tools involved in the development and IT operations.

In a DevOps model, teams are no longer ‘siloed,’ and integration between groups is the norm. Collaboration around shared objectives is common. Occasionally, teams will merge, and roles that would have traditionally been limited to one part of the development lifecycle will work over a much wider scope – for example, the rise of ‘Software Developers in Test’, or SDET. Rather than traditional user acceptance testing, SDETs create and run automated test codes.

DevOps is often represented by the continuous loop to show continuous delivery

DevOps is often represented by the continuous loop to show continuous delivery

So, if we can’t easily ask, “what is DevOps?”, maybe we should look at “Why DevOps?”, instead. Or, to put it another way, what is DevOps trying to achieve? Well, DevOps grew up around the increasing demand to deliver new features and new technology quickly, without sacrificing the performance and stability of the product – allowing companies to deliver releases more rapidly, more often and more easily. This practice is often known as continuous delivery.

DevOps principles

With DevOps being a collection of philosophies, tools, and practices, rather than a single defined process, how can a company be sure that they are working towards a culture of continuous delivery? Well, there are some principles and best practices that companies can employ to maximize their chances of delivering faster and more reliable updates.

DevOpsGroup considers there to be five main principles that any DevOps model should be founded on – this is known as the CALMS model.

In this model, culture sits at the foundation of any business transformation supporting the other principles. It is of critical importance that a DevOps team embraces the change and works toward fostering a culture of collaboration, openness, and shared objectives.

Supported by the culture are the 4 other key principles to ensure DevOps is successful. Automation is a significant ‘pillar’ of DevOps methodologies, ensuring that near-instantaneous feedback can be gathered through automated processes. Lean IT is about instilling an agile mindset into the team and its processes, ensuring the focus is always on producing value for the end-user by taking a lean approach to system thinking and requirements.

This lean thinking extends to the next principle; Measurement. It’s important in any continuous delivery environment that teams do not spend time measuring extraneous KPI’s. Keep it simple and measure the right things – those stats that will help guide you to customer value and allow you to find and fix faults quickly. The final principle in this model is a practical application of the cultural foundation – make sure you collaborate and share experiences and learnings. Take responsibility for sharing goals.

The CALMS model sets out the principles of DevOps

The CALMS model sets out the principles of DevOps

What are the benefits?

DevOps has some big advantages, both on the processes and culture of an organization.

The cultural mindset change, that is necessary to facilitate the move to a DevOps model, leads to a much more collaborative environment. The culture of shared responsibility should foster a greater feeling of trust between teams, as all are now working toward the same outcomes and objectives.

The emphasis on repeatability and automation means that it also becomes easier to scale development processes, allowing for greater flexibility and agility within the company. The increase in the speed and availability of feedback afforded by automation allows for teams to react quicker to create faster fixes to any issues that arise.

If you’d like to read more on DevOps, two books that I’d recommend you add to your reading list are “The Goal: A Process of Ongoing Improvement” by Eliyahu M. Goldratt (an older and less IT-focused look at continuous improvement), and “The Phoenix Project” by Gene Kim, Kevin Behr, and George Spafford (a more recent and IT-focused novel about DevOps).

What does it mean for Product Management?

So, what does DevOps mean for product management? Fundamentally, the approach enables product managers to embrace lean and agile practices – maybe even to go beyond them.

DevOps can lead to a culture where product managers can run experiments with confidence, testing different versions quickly and easily with a small number of customers. For example, having monitoring in-place to know how those tests are going gives confidence to the product manager to know they can switch back to a safe version quickly and consistently if needed.

With the rise of concepts such as Continuous Integration and Continuous Delivery (or Deployment – but let’s stay out of that religious war!) in the development and operations world, many of the barriers to putting new versions out to customers have fallen away. The development team has confidence that what they have built passes all the tests virtually instantly in many cases. And operations can put things live at the drop of a hat.

But, is it always sensible to do this? To quote Nicole Forsgren, a leading voice in the DevOps world and author of Accelerate. She has been quoted as saying “Pushing code to production should be a business decision and not a technical constraint.” By this, she means that having that technical capability to put the code onto your servers instantly is a great and powerful capability, which is the best practice to have. But, when it comes to actually make it live for a customer to use and release it, that is a choice that is for the business. Often that business decision belongs to the product manager. In a B2C context, the implications may be minor. So, you might be able to release 100 times a day. But, in a B2B context, every time you change the product that might trigger a wave of changes and integration work that your clients have to do – only doing this every month or more might make more sense. If there is a problem, though, you shouldn’t have to wait for a monthly release window to go live with a fix. This is when the capability comes in very important!

As anyone who has attended our 3-day training course will know, we recommend that collaboration between three key groups (product, development/test and design/UX) is best practice for ensuring requirements that deliver. Through this team, we can ensure that the 4 big risks as identified by Marty Cagan are covered.

Valuable – Product usually lead on this dimension
Usable – Design / UX usually lead on this dimension
Feasible – Development / Test usually lead on this dimension
Viable – Product usually lead on this dimension

The four ‘big risks’ of product requirements… Should there be a fifth?

The four ‘big risks’ of product requirements… Should there be a fifth?

Maybe with the inclusion of DevOps, we should be expanding that team and adding a 5th significant risk to consider:

Operatable – Operations would hopefully take the lead here!

Ensuring that those operational requirements are covered, that may have traditionally been covered as “non-functional” requirements, is increasingly important. It ensures that when a product is in-life it can be run and maintained in an efficient manner. If you consider a SaaS platform, in particular, this is important.

As an example, Netflix has a DevOps culture, although it doesn’t call it by that name. The team focuses on ensuring that the development team doesn’t get bogged down in operational details. For example, instead of asking the software engineers to figure out how to spin-up a host on a cloud provider, they take care of it. But they don’t do it for them; they do it by building tools that the team can use to do the job. They ensure that development teams can be efficient and focus on adding value without dealing with this detail.

DevOps emphasizes the shift from a Project to a Product mindset, especially for the IT community. For a long time, they have used the language of projects. Those projects were run for a finite amount of time to achieve something and then ended. If you have a product with customers, using this approach of taking the team away doesn’t fit. The product needs to be maintained and evolved; the team that created it are the ones best suited to do that work, so keeping the team together makes a lot of sense. Marty Cagan classifies businesses as either IT companies, with the old project mindset, or Product companies, the Product mindset. Mik Kersten also looks at this in his book Project to Product.

One operating difference I have found is that DevOps teams tend to prefer Kanban as their working model. Kanban emphasizes the flow of work through the system, delivering quickly, but accepts constant chop and change. Most development teams, on the other hand, tend to prefer Scrum, which emphasizes small batches of work delivered in a (short) time-bound manner. This can cause some friction when working closely together, especially if working in the same fully cross-functional team. It may be one reason why there is the rise of so-called ‘Scrumban’.


DevOps offers enormous potential for improving the effectiveness and efficiency with which a genuinely cross-functional product team can deliver. It ensures that development, in particular, can focus on adding customer value and not get lost in the weeds of operational tasks. It allows product management to confidently experiment and monitor how their product is performing; while giving the ability to respond quickly to issues in a live product. If you are interested, the DevOpsGroup might be able to help you learn more about it and even help you build the capabilities.

DevOps is not a new fad; it is a philosophy that has been around for some time and looks to be here to stay. It is highly complementary to how modern digital product teams work and if you are not already doing some (or all) of it, we would lay odds on it coming to your business soon


Phil Hornby
Product Focus Senior Consultant and Independent Consultant

Thanks to and contributions by:

Rael Winters and Edward Pearson

DevOpsGroup Product Managers

The post DevOps 101 for Product Management – how it can empower you! appeared first on Product Focus.

]]> 0
Some things change – and some things don’t Mon, 23 Sep 2019 11:05:51 +0000 We've updated our Product Activities Framework to reflects the trends we’ve seen emerging in product management. However most of the key product management activities remain the same.

Use the framework to work out who does what in your business.

The post Some things change – and some things don’t appeared first on Product Focus.

I’ve been working in technology product management for over 25 years, and when people say to me it must have changed a lot I pause, try to look wise and say “well… yes and no”.

The basics of product management haven’t changed. It’s still about making sure we’ve got the right proposition for the right audience with the right messages. It’s still about building the right product for the customer. It’s still about making sure the product makes commercial sense for the business as well as the customer. And it’s still about providing leadership within the organization at a product level.

However, there are a number of areas that I have seen change. There is an increasing emphasis on product managers needing to understand their customers and markets in more depth. In B2B companies selling to big customers, there is a greater focus on a productized approach, i.e. a focus on repeatability and reusability to give economies of scale and greater profitability – rather than delivering a series of projects. Moreover, product management seems to be taken more seriously in many companies. It’s seen as a profession rather than a job and given a seat at the top table.

Another key thing that has changed is the product management of software-based products. This includes the rise and rise of Agile software development approaches. It includes a much stronger focus on the user experience and the discovery techniques used to find out what customers value. It also includes much more use of data and customer insight to drive product design. These ideas have now spread across all of product management.

The Product Activities Framework

We produced the first version of our Product Activities Framework 14 years ago. Created for product managers, product marketers and others that work on products, the framework shows all the product management activities that take place in a company with products. It helps product people think about who does what, what they own, what’s done by others, and what might be missing.

Strategic Product Activities

The framework groups activities into three key areas. Strategic Product Activities which are about working out what the right product is for the business. Inbound activities which are about working within the business to help deliver or support the product. Also, Outbound activities are those outward-facing activities that help sell the product.

These three areas cover 20 different activities. However, it’s unusual for one role to own all of these activities; they are usually split across a number of different product roles, including Product Management, Product Marketing, and Product Owners.

So, what’s changed?

Clients consistently give us great feedback on how useful they’ve found the framework, and now we’ve made it even better!

This new update reflects the trends we’ve seen emerging and now establishing themselves as a core part of product management.

In the updated framework, most of the Strategic Product Activities remain unchanged and are as important as ever to professional product management.

In the Inbound Activities, we’ve added ‘discovery and design’. This is the process of defining and testing a hypothesis by building mock-ups, prototypes, MVPs, and product versions to help understand what is valuable to customers. It’s about using these insights for product design and to improve the customer and user experience.

We’ve also tightened up some of the Outbound Activities to talk more about significant developments in the digital space like content marketing and supporting digital marketing.

Product management means different things to different people

If you’ve only seen product management in action in one or two companies, it’s easy to assume that’s the way it’s done everywhere else.

We work across the globe, and we know product management continues to be done differently from one company to the next. For example, in startups, it’s done by senior management, whereas in large multinationals it can be fragmented across a range of specialist departments.

Another variable affecting product management is the level of maturity the function or department has. Many companies are just beginning to introduce product management; others do it well but have no one with the title of product manager.

Also, guess what, not every product out there is a mass-market online software product like Facebook or Spotify. In our 2019 Industry Survey, only 21.2% of product people managed software-only products.

Types of Product 2019

That means the job of product management in the majority of companies is not dealing with just software. It can involve physical products, services, selling to businesses, working with partners, internal product management and the challenge of handling multiple products in multiple markets.

More than that, as a product manager, your context defines what you need to do in your job. The type of product you manage; your market; your level of seniority; the resources available; the maturity of product management in your business, all contribute to what’s important. Furthermore, you’re usually not starting with a clean sheet … you inherit a situation and have to make the best of it.

In short – it’s complex and messy.

That’s why on our training we don’t prescribe one single approach to product management – we provide you with a toolkit of best practice and approaches allowing you to select the ones that make sense to your context.

A tool to help understand product management

Using a tool like the Product Activities Framework can help make sense of who does what in any company. You can download the latest Product Activity Framework Infographic (link here) and stick it on your wall.

Product Activities Framework

Ian Lunn
Director, Product Focus

The post Some things change – and some things don’t appeared first on Product Focus.

]]> 0
Tools to help product management leaders under pressure Mon, 02 Sep 2019 15:08:35 +0000 As a product team leader, finding time to work out how to improve the performance of your team or department can be tough.

In this blog we provide some useful tools and advice.

The post Tools to help product management leaders under pressure appeared first on Product Focus.

If you lead a product team, you will be busy. Usually very busy.

There will be ad-hoc demands from senior management; there will be urgent questions from your team; short-term crises to deal with; fires to put out; and important decisions that have to be made – apparently today!

Improving the performance of your product management function is something you know you should think about … but it’s tough to find the time. So, nothing happens until you get to a trigger point where something forces you to make a change.

Some triggers points that we’ve seen are:

  1. There is spiraling demand on your product team’s time – expectations are not being met, performance has dropped.
  2. You’re adding a new team of product people to your existing team after a merger or significant re-organization – they do things differently, and it’s causing problems.
  3. You’ve got a new boss who wants product management to become more strategic and leading – you’re not sure what that really means.
  4. Some of your best product people are quitting and you’re not sure why.
  5. You’ve come from another part of the business and you’re running product management for the first time – you’re not sure what to focus on first?

If you’re facing any of these situations, we sympathize!

More than that – we can give you some advice and tools to help you out.

Knowing what ‘good’ looks like

Many senior people you work with may only have a vague idea of what product management does. They don’t understand what ‘good’ looks like for a product management function. They see a product manager and think there’s someone who can fix my product problem.

One way to help you explain things is to describe the level of maturity of product management in your business. Our Product Management Maturity Model shows three levels of maturity (Ad-hoc, Managed, Leading) split across five areas –  leadership, organization, people and the tools and processes they use.

Product Management Maturity Model diagram

Product Management Maturity Model

Product Management Maturity Model from Product Focus

Product Management Maturity Model – click to open

The Maturity Model gives a structure to think about where you are now as a product team and where you want to be. You can download the infographic to work through the checklists to understand how you are doing.

Most businesses find that their level of maturity varies across the five different areas. Also, performance within a company will vary over time and across the business. In our reviews, we often find some pockets of excellence and other areas that are woefully deficient.

However, we do find this model is a useful tool as it moves the discussion on from talking about symptoms, e.g. late deliveries or poor product revenues, to looking at what the root causes might be of poor performance.

How to find the root cause(s) of poor performance

The diagram below uses the Maturity Model in a fishbone diagram to help you diagnose what might be causing poor product management performance. Working from right to left, you can use it to identify the root cause(s).


Product Management Maturity Model fishbone diagram

1 Roadmaps, Business Cases, Propositions, Plans, Pricing, Requirements, etc.
2 Communications, leadership, stakeholder management, influencing, political
3 Products, customers, markets, technology, competitors, suppliers
4 Processes, structure, contacts, governance

What are the typical issues you will face?

We know from our 2019 industry survey that the top three issues that product managers have are:

  1. Product management responsibilities are not clearly defined and overlap with other roles
  2. Lack of time or resources – product managers are overloaded or spread too thinly
  3. Product management lacks power or influence – its value is not appreciated

So, you will likely need to grapple with some or all of these. If you are affected by the first one, you may want to look at our Product Activities Framework. It shows all the product management activities that should be going on in a company with products. It’s an excellent tool to help you clarify who does what in any product-based business.

Start with an audit

You may think you know all the problems already, but spending time to talk to the different stakeholders and any existing product people is critical. It helps build relationships, shows you care, and you will probably learn things that you didn’t already know.

Another helpful tool to use when discussing the key issues impacting the success of a product function is our Product Management Dashboard. It looks at three critical areas – the purpose of product management in the business, key organizational challenges and ways of working.

Product Management Dashboard from Product Focus

Product Management Dashboard – click to open

For example, if the team is doing too much firefighting, then you can describe the pointer on the Role dial as being too far to the left, i.e. there is too much tactical work. If there is confusion on what the different roles should do, you can use the Product Activity Split to highlight the point. If product management is being done in different ways across the business, you can say the Tools and Process Dial is too far to the left (ad-hoc).

Selling the value of product management

Whatever your situation, you need to be selling the value of product management within the business. This will give you the necessary buy-in and ‘wiggle-room’ from senior stakeholders to make the changes required.

A resource that can help you do this is our story ‘What’s the point of product management’. It outlines a journey that you may already be on as a business. To begin with, product management is a mess, and the story describes what happens to change into a world class product management function. It’s full of arguments and ideas that you can use with your senior management.

A roadmap for product management

One way of describing your plans for improving product management is to talk about ‘a roadmap for product management’. It’s a nice way of presenting the things you need to change or put in place for the team. It may include a re-organization, training, improving key processes, a portfolio analysis exercise, or clarifying roles. Our product management reviews can help you identify what to do or why not attend our Product Management Leadership Forum.

Final thoughts

Whether you are one of the lucky few with time to focus on how to develop and grow your team or one of those faced with the need to change through a trigger point; these tools are an effective way to think about the problems, engage your team and wider business, and implement value-adding and effective change.

Leadership can be a lonely place, so if you need some help at one of these critical points in time why not get in touch.

Ian Lunn
Director, Product Focus

The post Tools to help product management leaders under pressure appeared first on Product Focus.

]]> 0
A guide to Zen Agile Wed, 03 Jul 2019 11:49:08 +0000 Agile is one of the most discussed topics in tech and a potential battleground between Development and Management.

Read this entertaining blog by Aidan Dunphy on how to handle Agile in a Zen-like fashion.

The post A guide to Zen Agile appeared first on Product Focus.

… or “Sh*t happens, get over it”

“Agile” is one of the most discussed #topics in tech. You might say that we’re in a ‘post-agile’ era, with it being de rigueur for software development.

However, just as much is written about the tendency of senior management to think it’s a magic trick; enabling teams to do more with less (faster) rather than something they themselves need to adopt.

Is agility a higher state attainable only by elite Silicon Valley outfits like Spotify, or is it something that any company can achieve?

Eager to set themselves apart from the crowd, certain members of product management royalty have started to pour scorn on Agile. They point out the prevalence of a dogmatic, cargo-cultish zeal for Scrum.

If being agile (note the lower-case “a”) really were a bad thing, then what would be the alternative? How about the Stolid framework, or the Denial method?

So, what is this Agile thing anyway?

It’s important to remember that Scrum and Agile are different things – it is perfectly possible to use Scrum without being Agile, and vice versa. So, when Drift CEO David Cancel shouts “I hate Agile!” Perhaps what he means is; ‘I hate when people do a Scrum thing and think that means they’re Agile!’

It’s understandable that some are calling out the enormous quantity of noise generated by the word “Agile”, especially when it’s capitalised.

In 2016, a Deloitte analyst inadvertently portrayed this maelstrom of jargon in his infamous 2016 ‘tube map’ diagram. This diagram showed (some of) the various tools and practices advocated in the Agile world:

‘tube map’ diagram

Christopher Webb’s infamous Agile tube diagram highlights the complexity of Agile – it’s more than just scrum!

Ugh – easy to see why someone might think Agile has lost its way.

Agile is something you should be, not something you should do, and no tool will make you agile. This comes more easily to some than others, particularly those blessed with a short attention span.

Let me give you some personal examples…

In my school days, I was frequently the recipient of an airborne board rubber, or a palm-stinging tawse for staring out of the window, forgetting to do my homework, turning up wearing the wrong clothes, etc. Changing my mind and accepting new evidence isn’t a problem, as I sometimes can’t remember what my point of view was yesterday!

A former CEO I worked for, couldn’t get his head around why I’d sometimes reposition half-way through a meeting. His preference was to relentlessly persevere with “the plan”, an always-out-of-reach goal to “arrive in style”. Needless to say, he was a former project manager from whom the word “agile” literally elicited a wince.

Living with such constraints is an ordeal for agile thinkers.

As a university student, I was once rushing to catch a train home to Durham (13 minutes) at the end of a busy week. I ran into the station and onto, what I thought was, the 17:25 waiting at platform 2. Imagine my dismay when we departed in the wrong direction, and then when the guard confirmed that the first stop was Edinburgh (2 hours). My commute had just turned into a round trip to Scotland.

Most of it was spent sitting in an empty carriage and with the darkness outside I couldn’t even admire the scenery. Not planning for this impromptu trip, I had nothing to read other than the train company’s brochure; exhorting me to take a day trip to historic Durham. It’s not unlike working in a project-driven company and reading blogs about A/agile.

On another occasion (stay with me); when working as a consultant, I rushed out of the office, jumped in the car and was bombing southward from Newcastle on the A1. As I passed Scotch Corner services, a sudden bolt of awareness struck cold fear in my spine: Where was I going? Stopping at Leeming Bar, I got my laptop out to check my diary (no smartphones yet) and confirmed that I should have been heading North to Glenrothes. Fortunately, the unintended detour added only 90 minutes to my journey.

Did you spot the analogy?

The train is Waterfall and the car, Agile. In both cases, I took the wrong initial course. But, on the train journey, I had to continue until the bitter end.

I did ask the guard if he would stop the train to let me off, but he just laughed at me with the incredulity of a PRINCE2 programme manager when you ask them to pivot.

For me, being anything other than agile is effectively to pretend that (a) you can predict the future and (b) sticking to a bad plan is better than changing it. So why does Waterfall still exist, given its dire reputation in product development?

Letting go of the future is counter-intuitive

We, humans, are instinctively able to discern patterns in things. We use this to foretell the future by extrapolating from our past experiences. Side effects of this include an emotional need to know what’s going to happen, and a predisposition to confirmation bias. Doing a familiar task makes you feel like you’re on safe ground and you can go a long way along the road to damnation before reality intervenes.

So, when planning a Waterfall project, everyone involved conspires to delude themselves that they’re going to release ‘on time’ and ‘on budget’. Execs push a date at which the release must happen, and delivery teams make promises based on estimates. Devs complain about this, pointing out that it’s impossible to accurately forecast software development, so someone adds ‘contingency’ to the made-up numbers. Everyone starts out feeling comfortable and positive because there is a plan.

Before long, however, stakeholders start to wonder what’s happening. As there is, as yet, no software to be seen, their nerves start to jangle about the pace of progress. They enquire into how things are going, only to be told that “There’s nothing to see yet, we’re still architecting the platform.”

The lack of visible progress on a waterfall project can lead to some nervy stakeholders

The anxiety builds to the point where they demand to know whether the deadline is going to be met and that something tangible is produced. The delivery team grumbles about ‘scope creep’, ‘changing requirements’ and having to make ‘shiny’ stuff. This negativity is driven by a growing feeling that control is slipping from their grasp.

At the same time, suspicion is growing from people outside the team who ‘just don’t understand how hard this is’. The deadline is extended, tempers fray, additional pressure is heaped on the team and people quit. We’ve all seen it before. When running a project this way, you should start out by writing the post-mortem!

In truth, it’s not feasible to accurately predict how a software project will pan out, as the control was never really there in the first place. This is the main reason for the ‘inspect and adapt’ concept in Agile.

This encourages the delivery team to review their progress early and often, thus reducing the risk of doing the wrong thing for a long time. You may have seen the following model for comparing risk between Agile and Waterfall methods :

Models comparing risk across Agile & Waterfall – But, in reality, how accurate is it?

The idea is that in a Waterfall project risk remains high until delivery. Whereas, in Agile the risk is reduced from an early stage by iterative inspection and adaptation.

However, this analysis of Waterfall is rather optimistic. In practice, it often creates a graceful, slow-motion failure, founded on stated prejudices (AKA “requirements”). Like a computer programme, the project will deliver what it has been set up to do, however unhelpful.

A bulletproof change control procedure will cover the Project Manager, and even make them look good. The aim is not to create value, it’s to ensure that a plan is followed. Boxes ticked, meetings minuted, excuses made. All too often the outcome is an unrecoverable failure and, having spent so long building the wrong thing, there’s no budget left to rectify it. First-mover advantage has been lost.

The deadline delusion

As Benjamin Franklin would have written, were he a project manager: “In this world, only two things are certain; deadlines and liquidated damages.”

It’s Agile blasphemy, but also an inconvenient truth, that deadlines are inevitable in business. Building a product costs money and unless you’re Google or in the Silicon Valley VC bubble, there is generally a finite amount of it available. Therefore, stakeholders are understandably keen to spend as little time as possible spending it. Unfortunately, in software projects, deadlines are nearly always missed. This can be because:

  • Customers always want stuff yesterday, and your competitor is threatening to give it to them, leading to pressure to say “Yes, soon”;
  • Technical people often overestimate their abilities and neglect to account for mistakes, lost time and unforeseen circumstances;
  • Once the team is making something, they feel good and fall into the trap of thinking there is plenty of time left. Only when things are obviously off track does anyone intervene, and by then it’s too late.

In fact, if you meet a deadline, it’s probably because the stakeholders were prepared to overpay to guarantee it. This is an uncommon situation in commercial product development, as money is generally most definitely an object.

Transcending the tyranny

How to escape this?

Permit me one more confessional anecdote: As a heavy smoker in my twenties, I resisted giving up for many years. I was unable to countenance a future as a clean-living kill-joy. I felt that my life’s course was already set and that I was most of the way through it. When I finally decided to quit it was genuinely terrifying for me because it felt like dying. My personality, based on the ‘smoker/rebel’ template, was ending and I didn’t know whether there was life after the death of this self-image. It was a traumatic experience, but I survived (obv), and this major version upgrade taught me some life-lessons.

Lesson 1: The only thing that really matters is what happens next

Breaking my self-fulfilling prophecy that I’d always be a smoker was hard. I’d constructed a mental life script for myself, with a sense of inevitability based on my sense of self. However, you will remember from studying the Copenhagen interpretation of quantum mechanics (yeah?), that cause and effect at the macro scale is an illusion. Although it’s cosmically unlikely, anything and everything can (and some say will) happen next. Gross effects are averages of tiny random fluctuations.

This flies in the face of human intuition, which although generally serves us well, also suffers from systemic faults such as the sunk cost fallacy. We tend to persevere with a fruitless course of action because of the cost already incurred. We think “I’ve had the bad luck, some good is due soon!” Nope, any money you’ve wasted on a product is now in the past, and the only factors governing your future success are happening right now.

Great products, like Airbnb, came about as a result of many sprints; with many mistakes and brave decisions made along the way. A stretched analogy perhaps, but life and business are anything but deterministic. Or, to put it another way, take one step at a time.

Learning 2: If you decide to keep going for something, you’ll probably get there, eventually.

One day, around a year after quitting smoking, I realised that I was no longer thinking about it all the time and had no inclination to go back. This only happened because I had decided on 17th March 2001 at 13:35 GMT to become a non-smoker. A definite goal, but with unspecific outcomes and an uncertain time scale.

Similarly, my car trip had a destination (despite the detour to Scotch Corner). If there had been no ‘north star’ goal, I may have found myself endlessly negotiating the one-way system in Middlesbrough – keeping very busy but not actually going anywhere. To paraphrase Lewis Carroll, “If you don’t know where you’re going, any road will take you there.”

Agile is not random. Rather, it’s mindful pragmatism that keeps you moving in the right direction. You continually apply course corrections, but always with a destination in mind. Rather, like driving on the A1, it requires your unwavering attention. You constantly adjust your direction, mostly minor changes, but in the case of a mission-critical blockage/error, it can be a pivot (e.g. realising it’s too late to get to Glenrothes and deciding to visit a client in Redcar instead).

Fans of classical project management will argue that this can be handled via change control. However, such frameworks are predicated on the assumption that change is an exception.

Conversely, you can think of Agile as continuous change control. Although, we shouldn’t talk about “change” and instead recognise, and indeed embrace, uncertainty. Throughout my career, I’ve heard delivery teams complain about changing requirements and “scope creep”. In most cases, the client hadn’t really changed their requirements. It was just the implications of their vague ambitions had become progressively clearer on close inspection.

Learning 3: Fear causes all the trouble

Channelling that great business philosophy guru, Yoda: “Fear leads to negativity; negativity leads to inertia; inertia leads to poor quarterly results.”

The reality is that it doesn’t matter how much you plan, things aren’t really under your control. There’s no point being afraid. The only thing you should fear is unfounded and bearish market sentiment (another delusion caused by projecting the past into the future), which is most definitely a #firstworldproblem.

What’s the worst that can happen? Well, you could lose your job? Faced with this worst-case scenario, It’s worth asking yourself; “If I’m miserable here because of constrained thinking, lack of trust and systemic fear, shouldn’t I go somewhere else?”

However, it is disruptive to have to keep switching jobs. So, how can you overcome the deadline delusions and control-freakery?

The trick is to understand that stakeholders are also prone to fear. They usually don’t grasp Agile and expect to see a linear progression, such as you might see with a house taking shape on a building site. However, making a new product is far less predictable than making a building and it’s important to understand how stakeholder confidence changes over time:

These diagrams show how stakeholder confidence may develop over the lifecycle of a project.

In the Waterfall case, confidence will be either restored or shattered completely at release time, depending on whether the product meets expectations that have built up over the project.

In the Agile case, early confidence can be dented as incomplete stages of the product are produced by the delivery team. But, so long as the team keeps taking feedback, confidence builds as subsequent iterations move visibly closer to a market-ready product. Jam might be tomorrow, but at least today it’s sugar. Then the day after tomorrow it’s scones and jam, and one day it will be the full afternoon tea.

A plan is not a goal – it’s a tool, and an adjustable one at that.

If you’re building a business and need some software made, you will probably have some idea of what you want your product to be. You will also need assurances from your product team that they can build it in a reasonable timescale, without busting your budget.

So, how to fix the three corners of the scope/resource/time triangle?

Traditionally; this would be achieved by spending a lot of time analysing the requirements in detail, planning exactly what’s going to be built, estimating it, then adding contingency and a change management process. If a high degree of confidence in the time and cost budget is achieved, the price is often accepting a longer timescale and a higher risk that the eventual solution will fail to match requirements that emerge or change during the project.

Agile is often seen as a silver bullet. Don’t plan beyond one sprint! Pivot every now and again! Prioritise everything, brutally! Que sera sera! Zealots will shout down any talk of roadmaps, planning or strategy, and take agile to its logical extreme, one-day sprints (!?). Why stop there? Why not have one hour or one-minute sprints? In fact, why don’t you just let everyone be their own singular Scrum team and do whatever they like? ULTIMATE AGILITY!

Of course, I’m being a bit silly and nobody would take this seriously as a business approach (you would think). Businesses happen because someone had a vision and pursued it with vigour and persistence, in the face of adversity. It is the founder who takes a punt on and is accountable for, an idea. Agile is great for handling a change of direction in the detail or even means of execution. But, if the big idea fails, the business is gone.

Building a business needs planning, but only for the “how”, not the “why”. To achieve the necessary blend of direction and agility, various tools can be used. I’m personally a fan of the ‘Three Horizons of Innovation” investment model (The Alchemy of Growth, Baghai, Coley, White, 1999):

The ‘Three Horizons’ of Innovation model can help us plan our current and future resources effectively

This framework suggests that you should invest 70% of your resources into this year’s problem (current product), 20% in the next generation product (say 1-2 years out), and 10% on horizon-scanning and new category products (3-5 years out).

Many of those third horizon products will be pushed out or never be realised while some next-gen product projects will fail.

This type of strategic view helps executives to organise their future planning, and at the same time illustrates the futility of trying to plan too far out. It also highlights the need for constraint on investment in the current product, as it will inevitably be superseded by the next- gen and new category replacements. Execs will be reassured that the Product Manager is capable of thinking strategically and won’t waste money on a product they’ve fallen in love with.

Relax, nothing is under control

To sum up with a Zen-like platitude…

Beware the duality trap, in which one believes they can plan the future of a product.

Learn to accept the reality of the current sprint, appreciate its innate business value; be comforted by your career prospects, which if you keep adding value, will transcend the noise of ephemeral shouty bosses.

Author’s bio

Aidan Dunphy is Chief Commercial Officer at global digital product consultancy hedgehog lab. His career in software spans more than two decades working in enterprise and consumer markets. Having held roles in all aspects and at all levels of the software industry, in recent years he has focussed on building Product Management and Strategy capability. Aidan’s passions are creating and discovering new value and evangelising the agile product strategy mindset.


The post A guide to Zen Agile appeared first on Product Focus.

]]> 0
Using the 5 Whys to Stop Firefighting and Become Proactive Fri, 07 Jun 2019 18:07:52 +0000 Many product managers spend too much of their time sorting out issues and putting out fires.

This blog helps you reduce your firefighting by changing perceptions, having a stronger focus on prioritization and addressing the root cause of issues.

The post Using the 5 Whys to Stop Firefighting and Become Proactive appeared first on Product Focus.

As a Product Manager, you will know that demands on your time are high. New projects are constantly landing in your inbox and it can be easy to spend a lot of time on tactical activities and fixing issues – often known as firefighting.

Firefighting is a common practice in product management. It’s a topic we have covered before (see our blog from 2016 here). Since then, the problem seems to have increased. Our most recent industry survey shows that respondents felt that 52% of their time is spent firefighting.

When you’re firefighting, in many respects, what you are actually doing is ‘papering over the cracks’ of an inefficient organization. In an ideal world, there would be processes and teams that deal with any ‘business as usual’ issues. This would allow product management to focus on the more strategic challenges of understanding customers and crafting the product vision for the future.

Firefighting has the potential to monopolize the majority of your time. At its worst, it can consume most of the resources from the entire product team and create a culture where firefighting becomes the assumed and accepted norm.

Firefighting vs planned activities

Over 50% of the average product manager’s time is spent firefighting. Product Focus Survey 2019

So, what can you do to break the firefighting cycle and become a more proactive product management function? In this blog, I will examine some of the tools that will help you to stop firefighting.

Changing Perceptions

While firefighting is particularly prevalent in new product functions, where the role of product management is not clearly defined, it can affect more mature teams too.  As product teams, we work with lots of other functions across the business. If those functions aren’t clear about what product management does, they can view any incoming issues that touch on the product as being the responsibility of the Product Manager to sort out. This is very attractive to them, as it gets the issue off their plate!

Often, the very act of firefighting perpetuates this perception! If product managers are seen to be firefighters, that’s what others assume their job is. And, occasionally we make life worse for ourselves because we want to be seen as the hero – the one who rides to the rescue to sort out any issue. It makes us feel good, yet, this again perpetuates an incorrect perception of the function.

So, how can we change this perception?  The best way to start is to say “no” more often. This sounds simple but saying no is often harder in real life – particularly where a firefighting culture is deeply embedded, or when we’re trying to create a good impression in a new job.

If someone says to you, ‘any product issue – the product manager should sort out’, maybe your response should be, ‘any product issue – the product manager should sort out who sorts it out’.  Yes, we need to make sure it’s fixed – but only by finding its most appropriate home so that when it happens again someone else deals with it.

I don’t think you can ever eliminate firefighting from product management, but you can minimize it by evangelizing what product management’s role is and the value it brings when working more strategic activities. See our thoughts on this – Selling the value of product management.

As a Product Manager, I was once accused of having ‘slopey shoulders’. At the time, I’m pretty sure it was not meant as a compliment! But changing perceptions will encounter some resistance at first. I certainly didn’t feel like I was ‘passing the buck’. I felt that I was placing the issue in the most appropriate place.

In hindsight, this ensured that I was utilizing my time effectively while allowing the relevant expert to fix the issue. This was good product management instincts. Chances are, in a cross-functional environment, it will be far more appropriate for another team to pick up the corrective action.

The 5 Whys

Finding the most appropriate person to resolve the issue becomes more apparent when you understand the root cause. A famous technique for establishing the root cause of any problem is the ‘5 Whys’.

The 5 Whys is a bit like the technique that small children use to understand the world. Children keep asking ‘why’ until you reach exasperation point and say, “Because I said so!”

At its most basic level, it’s about asking why until you drill down the levels to the core issue. 5 levels always seem to be enough to reach this root cause. The classic example given to illustrate this technique is to consider why a monument in Washington DC was deteriorating. The stonework was crumbling and, as a major tourist attraction, lots of money was being spent to keep it looking good.

The Washington Monument

The Washington Monument

The 1st why – Why was the monument deteriorating? Harsh chemicals were repeatedly used to clean the monument.

The 2nd why – Why were harsh chemicals needed? They were needed to clean off a large number of bird droppings plastered over the monument.

It would be easy to stop here and come to the conclusion that some form of bird-scaring device was needed. But if we continue through the process we can find another option that addresses the true root cause.

The 3rd why – Why were there a large number of bird droppings on the monument? There was a large population of spiders in and around the monument. These were extremely tasty and abundant for the birds to eat.

The 4th Why – Why was there a large population of spiders? Vast swarms of insects, on which the spiders feed, were drawn to the monument at dusk.

The final and 5th why – Why were swarms of insects drawn to the monument at dusk? The answer, the lighting of the monument in the evening attracted the local insects.

So, the solution was to change how the monument was lit-up in the evening to prevent swarms of insects.

From this example, we can see why it’s important to drill down to the root cause and not the first cause we come across. When stuck in a cycle of firefighting, the temptation can be to put in a sticking plaster solution so that the immediate problem is off your desk, but that may not stop it coming back again in the future.


Just as we know not all projects that will pass over our desks are created equal, we should also realize that it’s the same with problems. Not all problems are deserving of your time and attention.

When a new issue or request comes to you, do you have a process for deciding how you should act? A little mental checklist that you go through to try and avoid ‘knee-jerk’ reactions and ‘time sinks’.

Particularly if you are new to product management, the temptation is to think, “It’s to do with my product, so it must be my responsibility.” By having a quick method of analyzing incoming requests it will help you avoid this trap.

The following method allows you to analyze incoming issues and make decisions on how to prioritize them.

Analyzing diamond

How to prioritize

When the problem arises, first think if you are the right person to handle this, or is it better sat somewhere more appropriate, with the specialist skills to resolve?

If it should sit with you, is it the right time to deal with it? Sometimes you can wait on a problem and it will go away or resolve itself. But, if it doesn’t go away, you can plan an appropriate time to devote your attention to the problem.

Another key thing to consider is whether you have enough info to progress it. Often you will need to do research before you can fix something. This could be reading up on possible solutions, but often it will involve bringing others into this discussion. Even if it is most appropriate that the problem sits with you, it should not stop you from leveraging the skills of others to resolve it. You should always be thinking ‘how are we going to solve it’ rather than ‘how am I going to solve it’.

A final thought on prioritization is to make sure to organize your daily activity. Knowing whether you have adequate time to devote to fixing an issue, depends on you knowing what your output for each day should look like.

One thing I do at the end of each day is to create a to-do list of the things I want to get done tomorrow – the things that will help me achieve my important goals. The next day when I break for a coffee and return to my desk, I review it and ask myself if what I’m going to work on next is really the best option. This is a great habit to get in to and will allow you to make better decisions on prioritizing your time.


So, how do you leave the firefighting behind and become more proactive and strategic? Firstly, it is important that we educate the business and change perceptions around what a product management team does.

Then we need some tools that will help us find the root cause of a problem, what the solution should be, and where that corrective action should sit. The 5 Whys will help you find a home for it, giving you more time to concentrate on your strategic activities.

Finally, becoming more proactive and strategic in your work makes it a more rewarding job. It feels much better than constantly being reactive – cleaning up the messes left by others. And you’ll be providing more value to the business and, in turn, making yourself worth more to the business!

Ian Lunn
Director, Product Focus

The post Using the 5 Whys to Stop Firefighting and Become Proactive appeared first on Product Focus.

]]> 0
Portfolio Management for Dummies Thu, 09 May 2019 13:36:56 +0000 Portfolio planning is essential to help your organization decide how it’s going to meet its objectives - get it wrong and you’ll miss targets, waste resources and frustrate stakeholders.

Whether you’re a product manager wanting to position your product with the senior team or a team leader involved in the portfolio planning process this blog provides some insights to the tools you can use to get a robust, transparent process.

The post Portfolio Management for Dummies appeared first on Product Focus.

Portfolio management is one of those topics that some product managers never worry about – whilst they might have heard of it, they don’t get involved.

Even those that manage a set of products might treat each as a discrete product and not worry too much about how to share their company’s resources between them.

But it does matter.

Let’s say you have a £10m budget and 10 products, should each be given £1m?

Clearly not, so how do you decide which product gets what?

Having a defined, systematic process for deciding where a company is going to make investments helps avoid wasting resources through a scattergun approach and helps limit the time wasted on knee-jerk reactions to short-term demands.

If you’re a product manager, looking after a single product then it matters to you because it impacts on the resources you’re going to get to spend on improving your product.

If you manage a portfolio then it provides a mechanism for you to make or to recommend investment decisions with your senior management team.

Standard tools

If you’re new to portfolio planning, then it can be tough knowing where to start.

But there are many tools that can help you think through what matters, give you clues about the investment that might be needed and to know where to focus your efforts. They also help you communicate your thinking and decisions to senior leaders in the business.

Product Lifecycles

We recently ran a webinar on lifecycles and have a new infographic that talks about decisions and areas of focus at different points in the lifecycle.

There’s a generic view of what matters at each point in the lifecycle. It’s worth understanding this even though your product and context may not be the same.

Targets commonly change during the lifecycle

Targets commonly change during the lifecycle

The red text on the graph points to possible business objectives at different stages of the product lifecycle. In the earliest stages of product introduction, market penetration and market share growth are usually key. There’s evidence that establishing a market leadership position in your target niche helps deliver higher profits as you are achieving benefits from scale and higher pricing.

As a product moves out of early introduction, the focus might shift to a different metric of value. For a commercial business, this is likely to be revenue as you seek to monetize your customers. For internal product managers or those who work in not-for-profit or open source businesses, other measures of business value would be used (e.g. number of users, number of clients, impact on the brand, pull through of other products…)

And finally, commercially oriented businesses will, at some point, shift the focus to profits – maximizing the value of the product by changing pricing or costs or some combination of the two.

There is a balance to be made in the portfolio. Early growth is expensive, with high investment in the product, and it’s only usually as things ramp into steady growth that there’s payback from the initial investment. When you think as a portfolio manager, you’ll need to balance the needs for investment in early-stage products with the profits that come from products that are more mature.


Another point of balance is between long term bets and in-life products. A useful model to help visualize and communicate this is 3 horizons from McKinsey.

Balance investment in today's products with plans for the mid and longer term

Balance investment in today’s products with plans for the mid and longer term

In the McKinsey model, as companies mature, they often face declining growth as innovation gives way to inertia. In order to achieve consistent levels of growth throughout their corporate lifetimes, companies must work on existing businesses while still considering areas they can grow in the future.

Horizon 1 is about maintaining and defending the core business (around 70% of investment goes here)

Horizon 2 is about nurturing emerging business (around 20% of investment goes here)

Horizon 3 is about creating genuinely new business – these are your moonshots (around 10% of investment goes here)

This model can be applied at both a strategic level but can also be used at a product level, e.g. as a roadmap approach with Horizon 1 becoming “Now”, Horizon 2 “Next” and Horizon 3 “Future”.

The timescales of each horizon can vary considerably. In some companies we’ve worked in, Horizon 1 looks out a year or less, horizon 2 goes out up to 3 years whereas in others Horizon 1 looks forward 3-5 years and Horizon 2 looks out 7-10 years. It all depends on their context – are they in a new industry, a fast-moving industry or something that’s more stable and mature?

The reality of investment is also often different from the McKinsey model. In some businesses with whom we’ve worked, innovation investment (horizon 2 and 3) is in the single digits.

There’s a reason this happens.

When an organization becomes successful at something, they tend to do more of it. That means they shift from what happened in their earliest days when they experimented and explored product and market opportunities to focusing more resources on things they know will work. It’s easy to get internal approval to exploit what is working well because it’s low-risk high-reward.

In some cases, the organization stagnates and dies because more innovative, disruptive businesses come and take the market away from them.

In other businesses, there’s often a wake-up call for the senior management as they recognize the lack of innovation and the pendulum of investment swings wildly from the short term to the long term. Then, some months later, existing customers start complaining and the pendulum swings back again to sort out in-life problems… and then the lack of forward planning gets recognized once more…and so the pendulum continues to cycle between the long and short term and back again. It’s not a great experience for those people working in these businesses!

Ideally, you’ll want to agree on a balance of investment for in-life products and their roadmap and longer-term initiatives.

Focused investment

So far, we’ve thought about positions in the lifecycle and balancing investment between in-life and future ideas.

These are useful perspectives but there’s really a need to consider the strengths of our business and our alignment with attractive markets.

That’s where another tool, the McKinsey  / General Electric Matrix comes into play.

You can use this to map your portfolio of products to see which play to your company’s strengths and which are playing in attractive markets.

Plot your products on the GE Matrix to visualize how things really are

Plot your products on the GE Matrix to visualize how things really are

Each blob on this graph represents a product. The size of the bubble shows revenue (or could be used to show profit) and the slice of the pie shows market share. The arrow shows our current forecast for how things are changing.

Where things aren’t quite right, the matrix gives guidance on where to focus.

The potential and challenges of each product.

Align your plans with the potential and challenges of each product.

You can use this to help facilitate your internal discussions. For example, if we’re in the central box at the bottom, Manage & Earn, you’ll probably want to spend time identifying attractive market segments and how sales, marketing, and development efforts can be focused to drive growth in those segments and find similar alternates to target.

If a product is in the Leader: Protect box in the top right, then you’ll probably ramp up your efforts to maximize the return on products.

The measurement of business strength and market attractiveness is not mandated. There are various factors that you might want to consider.

For example, an assessment of business strength might consider current market share, reputation, technology, competencies, quality, cost structure, key assets or other factors.

The assessment of markets might consider size and growth rate, profit potential, competitive intensity or other factors.

Assessing investment risk

The scoring used for the General Electric matrix might consider the risk associated with either the market place or product space. For example, the risk will increase if we’re moving into a completely new market.

However, a better tool to discuss risk is often the Ansoff matrix.

Ansoff has been around for decades but it’s proven to be a really useful model to help think through and to discuss risk.

It has two axes, Products, and Markets.

Use the Ansoff matrix to think about risk

Use the Ansoff matrix to think about risk

To use the tool, plot your ideas onto the matrix: enhancements to existing products in existing markets go in the bottom left; new market opportunities for existing products go in the top left; new product ideas to existing customer segments go in the bottom right whilst new products for new markets go in the top right.

Those in the bottom left are really low risk (but potentially low reward – they’re often simple extensions of existing products) whilst those in the top right are very high risk (but with potentially high reward – for example, by entering a rapidly growing market with high-profit potential).

One example to illustrate the value of Ansoff came from a client of ours. They had been phenomenally successful with near 100% penetration of their home market. They took the same products to remote markets and failed badly. They didn’t recognize the risks inherent in moving to a different market and so they failed to invest in the market research needed to understand the market differences and adapt their product and marketing to ensure these were addressed. A rapid recall and more thoughtful approach have seen them get back on track for success.

Putting it together

Portfolio planning is not something that most of us do every day. But, as a business, including it as part of six-monthly reviews or annual planning helps keep a focus on what’s important.

To get a robust, realistic view of the potential from products and innovative ideas there are a few things that need to be put in place.

  • Agreement on the tools that will be used (e.g. 3 horizons and GE Matrix).
  • Establishing a systematic process (with sufficient time) to gather input from senior leaders and from the product team helps create a set of initial recommendations for investment.
  • Including a peer review of the assumptions and drivers for growth to get a consistent view of the market.

Whether you’re a product manager or team leader, taking part in the process is a great opportunity to get senior buy-in to your ideas.

And an opportunity to show that you know what you’re talking about!

Andrew Dickenson
Product Focus Director

The post Portfolio Management for Dummies appeared first on Product Focus.

]]> 0