Tag: product delivery

  • 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.

  • 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.