John Bourne

Category: Product management

  • When strategy lands and delivery panics: Closing the gap without the drama

    I have struggled first-hand with the gap between strategic intent and real‑world digital delivery. I want to explore why that gap exists and how leaders can help digital delivery teams to be better supported through co‑creation, strategic alignment and practical collaboration.

    Strategy launch day

    The strategy deck lands well. The ambition feels right. Senior stakeholders nod.

    The delivery team are a bit quiet.

    Suddenly the room is full of questions that weren’t answered in the deck:

    • “Who actually owns this?”
    • “Do we stop doing what we are already working on?”
    • “Please tell me we’re not replatforming our CMS again?”

    This is the space between strategic intent and operational reality. And from where I’m standing, the space feels quite big.

    Mind the gap

    When a strategy deck lands with a team that hasn’t been close to its creation something predictable happens.

    • Teams translate abstract pillars into practical implications. As the slides hit the screen in the boardroom, I can see my team’s minds whirring:
      • “Customer-centric transformation” = a list of unimaginative personas.
      • “Data-driven decision-making” = re-reporting on user needs that we’ve already told them about.
      • “Platform modernisation” = a horrifying dependency map and unnecessary CMS upgrade.

    The team are confused and on the back foot and, frankly, are scared about what is to come. If the deck has any level of surprise to it, the team drift around in the ambiguity of the words they see in front of them.

    Why have strategy at all?

    Strategy is very important. I can’t do my job without it. I’m always so sad when I see a jaded team member roll their eyes at “just another load of words that don’t mean anything”. We have to find a way for them to buy into strategy that doesn’t feel hollow.

    Strategy shouldn’t have all the details, it’s not there for that. It’s not a detailed operational plan but a a direction setter. However, I find that teams often forget that detail when they receive a deck. I put this mostly to the fact they’ve not been close to it’s creation and the constant reiteration of why it’s being made in the first place.

    When strategy is presented as a finished artefact rather than a co-created direction, delivery teams don’t reject it outright. They stir over it and have an uncomfortable wait to see if it becomes reality or not.

    Until then, it is just a declaration.

    Shift from presentation to participation

    If strategy is going to resonate with the team, they need to be close to how it came to be.

    Instead of unveiling a completed strategy deck, treat the final phases of its development as a working session.

    It can’t just be the team leaders either – it has to include the whole team.

    Involving all of a digital team early will:

    • surface feasibility risks
    • build a shared language
    • help call out dependencies early
    • increase trust across the whole team

    A strategy that isn’t “heard” by the team is not a comms issue. It is a contribution and collaboration issue.

    What happens when you work together

    When digital teams are involved from the outset:

    • Roadmaps have already leaned towards the future direction direction when the strategy launches
    • Capacity assumptions are more realistic
    • Governance implications are anticipated
    • There is far less fear and far more hope

    The strategy deck doesn’t land as a disruption, but rather a confirmation.

  • User-first, even when it’s not

    I was recently thinking about work to improve team efficiency. We have a few slow processes, bits of technical debt and content proliferation problems that slow us down. I’d like to address them all, and on the face of it, they seem like “business-sided” issues.

    It’s easy to look at these problems and envisage a business analyst type role coming to support our process improvement or mechanism to cut down our content by restricting use of our content management system. They’re roles which are necessary, but it’s not the first thing I would like us to think of.

    To go back to basics for a sec, when I talk about the “user” I mean the person or group of people who start and end a user journey with us on any service we provide. Say, an undergrad student finding entry requirements or a member of staff trying to find a different team’s email address.

    Although the issues I raised at the start of this post don’t initially feel like “user” issues, I’d like to start with considering users to give us the appropriate steer.

    For example, let’s look at technical debt. We have code that runs some apps which is using very old, non-supported technology which could present a number of business risks. Clearly this is a priority to address. We could approach fixing this problem by saying we’ll replace like-for like with a new set of tech… but is this service still meeting a user need? Do we need to replace it at all? Is there now a better way to deliver this service to users since it was built? Do we even know how users interact with it? Without these sorts of questions being answered, we don’t know the direction of travel.

    How about content proliferation? Yes, that’s hard to manage and a drain on our team’s resources – but what’s the real issue here? A lot of content is a red flag… but not necessarily a real problem. If all that content has a user need, is findable and maintained that’s good, not bad! Ever increasing content that is not managed is a problem, because it slowly begins to veer away from meeting user needs. The issues we have as a team in trying to control it is driven entirely by making it better content for the people reading it. So, why would we start looking at this as a business problem? We need to understand what our users are looking for, so we can address the problems effectively.

    I’m often challenged with this approach by people saying “That level of research will take us a while to get to, so maybe we’d best jump right in” – but frankly that’s just wrong. Long-term costs of delivering the wrong thing far outweigh researching the right approach.

    There are two key elements that go alongside this:

    1. No guessing. We are not our users and, while we have insight and empathy, we don’t know until we have real evidence directly from those who do use the service we provide.
    2. Outcomes over outputs. If success to the business is something like “the delivery a new solution to replace that old one, measured by the existence of a new solution”, we will not address the true issues which can be hidden when you base success on an outcome like “success is the users of the service finding and performing their tasks quickly and easily, as measured by {insert appropriate success metrics here, like speed of task completion increases} “.

    I realise there is a level of pragmatism when it comes to many tasks we need to undertake, with inevitable shortcuts for some things, but we’ll never succeed in delivering better digital services without always pushing for user-first approaches, even when it looks like it’s not needed.

  • Welcome to “you’re wrong” night

    The Bill Hicks bit about welcoming his audience to “you’re wrong night” lives in my head rent free.

    Often, when I speak with well-intentioned colleagues who have a new and exciting idea, I instantly let them know they’ve come along to the “you’re wrong meeting”. It can feel to them like I’m simply trying to shut their idea down because I don’t like it.

    I don’t mean to. I almost always have no idea if their idea is a good one or not. But the minute I say “well, let’s do some discovery on that idea”, it feels like I’ve just told them they’re full of shit and that their idea isn’t good enough to get on with.

    The reaction

    The consequence of this tends to go one of two ways:

    Flight…

    • teams keep ideas to themselves
    • low engagement from stakeholders
    • tuning out of all digital engagement

    Or fight…

    • frustration at the perceived lack of action
    • demands to “just get on with it”
    • discovery phases appearing endless and inefficient

    What I want to encourage is a way of validating ideas that isn’t so scary and doesn’t feel like we’re just delaying or wasting valuable delivery time. In his Mind the Product interview, Anthony Marter suggests perhaps discovery is the wrong term, and I don’t disagree with him. There must be a better way to get people on board rather than just feel challenged.

    What even is discovery?

    “First, you need to discover whether there are real users out there that want this product… Second, you need to discover a product solution to this problem that is usable, useful, and feasible.”

    Marty Cagan
    Product Thought Leader

    I strongly suggest there is a constant level of work on that first part of user understanding. This way, when new ideas come along, we already know half of the answer. It also means idea validation doesn’t take forever, and we can provide better immediate feedback.

    The second part of that quote is a little harder, and depends on complexity of the problem. What shouldn’t happen is that the delivery team just get asked questions about the “feasibility” part.

    Delivery gonna deliver

    Many stakeholders don’t care what we think, or understand why we’d want to discover more. “You’re the delivery team – just get on with it!”.

    They’ve already understood why their idea is great… it’s a no-brainer to them.

    This is where I present my formal invitation to You’re Wrong Night.

    There could be all sorts of evidence to suggest you’re idea’s good, but if a delivery team have not been brought along with the discovery of why we’d do this, we won’t ever trust it, nor will we be motivated to achieve its goals.

    Why split discovery and delivery teams?

    I’ve been in both discovery and delivery teams. My experience has been that:

    1. Discovery teams get frustrated that the delivery team didn’t listen to what we gave them.
    2. Delivery teams get frustrated that the discovery phase wasn’t handed over well enough and has big gaps in what has been provided.

    This isn’t a failure of either. It’s the simple fact there is any form of handover. The more delivery teams are involved with discovery, the better the outcome of the product.

  • I wish I had more time to see you! Let’s still be friends?

    The other day I had a message out of the blue from a friend I’d not spoken to in a long time, asking how I was and to see if I wanted to meet up.

    I felt guilty. I’d not spoken to them in ages, but I really value their friendship. I didn’t want them to think I’d forgotten about them, I’ve just been busy with other life stuff.

    Cartoon image of a man looking at his phone looking quite anxious, like he's maybe guilty about something he's just read.

    I wrote back hastily to say sorry and explain how busy I’d been. “Let’s get a date in the diary! It’s been too long!”.

    I feel like a bad friend, but know that they understand why I’ve not seen them. Life is busy… I have young kids and live on a farm. The thing is, it’s not an unusual occurrence.

    It got me thinking about work. I am a Senior Product Manager across a large portfolio of work with a small team. I need to prioritise both the broad areas to focus on as well as features within any specific product. Sometimes I get an email asking “what’s happening with the update of my site?”, which I need to remind myself of, digging through the backlog. The similar feeling as I had with my friend starts to creep up on me…

    I then have a bunch of questions:

    • Do I get too many of these types of message?
    • Does that indicate that I’m doing something wrong?
    • How should I manage things so they’re not cut adrift?
    • How can I tell them I think they’re important, but maybe not on the top of the agenda?
    • How do I keep that relationship healthy, even if I’m not directly working on things they really care about?

    Emotions can get in the way

    When my friend got in touch, I was sad that I’d let communication with them slip. It’s easy to feel the same about a work collegue and then immediately feel like you need to make it up to them. You want to make it right.

    Should I reprioritise because of neglect in that relationship? Just because they got in touch, do I have to jump on that? I don’t think that’s right, so I don’t think it’s a good idea to get too emotionally attached.

    What does “I’ve been busy” mean to them?

    So, I tell them how sorry I am and that I’ve been so busy. What do they care? They just want an answer. So, how can I show them less about how busy I am, and what the priority is for their problem? Well, that’s what a backlog is for… right?

    What a product backlog means to me vs what it means to them

    I show them a backlog, and how much other work is prioritised above them. They think it’s a black hole. They still have a real problem they need to solve, and I’m blocking them.

    Sometimes this means they’ll find alternative routes to solve their issue which could be problematic. We’ve had many examples of people making their own rival website separate to the company site, just because we couldn’t put all the pictures they wanted on there. To solve that I need robust governance as well as a wider culture shift to get people to understand the bigger picture of what a website is for… but that won’t happen overnight. The work I need to do now is not show them how their feature is lower down a list, but how the stuff higher up the list is going to help them even more.

    How I want to manage this from now on

    You’re not a bad friend for not seeing everyone all the time, and you’re not a bad PM for having a large portfolio. But you are a bad PM if you’re not working in the open enough.

    I think the answer to my first question – Do I get too many of these types of message? – is yes. They’re a symptom of not being open enough and not dedicating enough time to explaining what I’m trying to do.

    I want to:

    1. Try harder to be pro-active.

      I should get out in front of people and invite more people to demos. I need to reduce the amount of messages from seemingly forgotten friends.
    2. Keep a focus on the big stuff that will help everyone.

      I don’t want to fire-fight everyone’s design issues on their bit of the site, I want a design system that everyone understands and buys into.

      I don’t want to fix the fact they can’t add a picture to their bespoke listing of facilities, I want a content model of “facilities” across the institute that makes for better holistic find-ability.

      Avoid promising features. I want to fix the bigger user need gaps, and that’s not reacting to the symptom, it’s fixing the cause.
    3. Find the time to explain it all.

      I want to take them for coffee and explain the context and why the future is looking bright. I need to hear them out too. Can they help me build a better picture to prioritise? Probably.