In this MTP Engage Manchester talk, Neil Vass, Principle Delivery Manager at the Co-op shares some of the recurring ways that we, as product people, disappoint. He includes the lessons he’s learned, and some useful tools to tackle the issue.

Every project has a fixed amount of disappointment, and it’s up to you to decide what to do about that James Shore “The Art of Agile Development”, 2007, paraphrased and paraphrasing

Common Ways of Disappointing People

The idea of projects has gone out of fashion in favour of rolling, iterating products with ever-evolving features and specifications. But any time someone wants a specific release or a deadline – and it’s not uncommon – they’re slipping into “project-mode”, where compromises have to be made, and expectations have to be managed.

As soon as you start trying to manage expectations, convince people that their vaunted visions are impossible to achieve in the timescale they’re imagining, or generally encourage people to scale back their ideas, you’re going to disappoint them. Sadly, this is a large part of the reality of stakeholder management. Of course, there are good and bad ways to work with stakeholders. To start with, let’s talk about some of the common ways that we will all, as product people, end up disappointing people.

Having the Courage to Discuss the Elephant in the Room

Often the challenges ahead are something that everyone tacitly agrees shouldn’t be discussed. The reality is that this is just storing up pain for later, so just bringing up these issues is an important step. However, if you make a mess of this process, you’re only going to make things worse. Stakeholders often have an idealised expectation of how their project will go, built up over a long period of time, and if you smash those expectations & that vision in the first interaction, you’re going to struggle to build a strong relationship with them.

Iterating Down to an MVP

Sometimes people come to you with what they think is a “stripped-down” version of what they’d like to launch, complete with expectations of costs and release-dates. They believe that they’ve presented you with an MVP, but think they’ve given you a 5-year roadmap. If at that point, you gently ask “What else can you drop?”, and start going through multiple cycles of slicing things out of their vision, you’re going to rapidly erode their enthusiasm and lose their willingness to engage with you constructively.

The truth is that “MVP” has different definitions in different companies. In some companies, it means the most stripped-down, minimised, descoped version of their idea that they’re ever going to get. Of course, it’s important to work towards a realistic agreement of what can be released, but the journey you take to that point makes all the difference.

“Everyone Else is Onboard – why are you Standing in the way?”

In a situation where your stakeholders have built alignment amongst themselves, or simply not considered the risks and uncertainties inherent in their project, they may create the perception (for themselves, and sometimes even for you as well) that you saying that there’s a problem is the actual problem – rather than anything in the project itself. You might feel the pressure to give in & move ahead but, as mentioned earlier, that’s just saving up the disappointment that you’ve all got a chance to act on – and minimise – now.

In the old days of waterfall, you’d have years of planning and research to quantify risks, frame uncertainties, and all agree on scope (realistic or otherwise). But now we have Agile, which should let you create and test an MVP a long way away from any deadlines, and we’ve created a strong sense of momentum and capability. However, while there is nuance, and large wells of collective knowledge about how we build products in the modern world when someone is already frantic to release something, you’re not going to sell them on the idea of an agile process.

A Toolkit for Not Disappointing People

The truth of the matter is that you will never be able to please all the people, all the time. You are inevitably going to disappoint stakeholders at some point. However, there are several things you can do to try and minimise that disappointment and to make sure that everyone involved in the process is clear on what the team is doing, why they’re doing it, and what the risks are.

Understand Negotiation

You might be inclined to treat managing stakeholders as negotiation and, if you’re senior or experienced, that might be an effective strategy. But what you’re discussing is not price or value, and negotiating on estimates is often just trading one difficult compromise for another, leaving everyone frustrated. There’s no point negotiating on estimates because the outcomes are never a true understanding of risks and uncertainties, or effective management of scope.

That said, the skills involved in negotiation are incredibly valuable. Software estimation isn’t really about negotiation at all. It’s about getting people to listen to each other and understand what’s being said while remembering that understanding is not the same thing as agreeing.

Change the Definition of MVP

When you’re trying to work in an agile fashion, it is crucially important that everyone involved has a common definition of what constitutes an MVP. However, the work of building alignment and shared knowledge of this needs to happen a long way away from the frantic panic of trying to hit a deadline. Find ways to gradually educate your stakeholders on what an “MVP” is intended to be, and how to design one, when there the pressure on the team is low.

It’s also worth remembering that ideas that aren’t acted on in a given sprint don’t necessarily just disappear and wither. They can be remembered and documented, and experimented with in the future (often at points where dramatic change is required), so someone’s great-idea-that-didn’t-make-this-sprint may yet be built.

Be Open About Uncertainty

As a general rule, people hate uncertainty. Experiments have suggested being in a scenario with a high certainty of negative outcomes is generally less stressful than being in a scenario with low certainty but fewer negative outcomes. Put plainly, we’d rather be certain of negative outcomes and have an unclear possibility of good ones. So when we have to tell our stakeholders “we don’t know” or “we’re not sure”, we’re working against an instinctual aversion to ambiguity.

To make the experience more palatable, try to clearly point to where the uncertainty is – which bits of the project, which technology or timeline questions, which strategic partnerships? This gives your stakeholders a sense of bounded uncertainty, and potentially the opportunity to help the team remove some of that uncertainty. It’s also worth being mindful of what Neil calls “The Cone of Uncertainty”, describing the scope and impact of decisions and different points along a project’s timeline. Decisions early on tend to be few, but with a huge impact on the ultimate outcomes. Later on, decisions are much smaller in impact, but much greater in number. Ensuring that the team has the support and the space to work through those appropriately is crucial to having a good chance of success.

Reading List

Neil’s toolkit and disappointment antipatterns are by no means an exhaustive list, and he has a handy workshop you can run in your company to help your peers develop a better understanding of these challenges. In the meantime, he recommends three particularly useful books you should read, to help you hone your skills in project estimation, stakeholder management, and minimising disappointment:

• Waltzing with Bears: Managing Risk on Software Projects by Timothy Lister and Tom DeMarco
• Software Estimation by Steve McConnell
• Getting to Yes by Roger Fisher and William Ury