Author: John Bourne

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

  • Addressing our technical deb… *ahem*… maintenance issues

    Most universities are in that group of organisations that live long before the internet era began. Many were at the forefront of the technology behind the internet.

    Did that mean they got their web-presence spot on and ran with it?

    No, it was the opposite.

    They started with no strategy, no governance and little regard for the ongoing management involved.

    That means for me, right now, delivering front end solutions fast and at scale is not happening. We drown in technical debt across so much of our infrastructure.

    Did you say technical debt? *COUGH* Sorry I was just sick in my mouth

    “Technical debt” is the sort of thing I hate saying and get laughed at when I do (among a worrying number of other phrases…). I’m now trying to refer to any tech debt work as “maintenance”.

    Recently I’ve been working on a project to align all our public facing website to be within a Design System. This has meant a lot of re-coding and tinkering with the design to… well, make everything look exactly the same as it does now.

    This is not sexy. It’s boring and gets shrugs when I tell people about it. But, trust me, it is valuable.

    Putting down the Content Design handbook

    I feel for the team who are migrating content from old to new. It’s not improving the content. Also, it’s a semi-automated process, so some of the things we switch over to the new world needs a bit of manual intervention.

    When it comes to poorly created content (which is frustratingly widespread with our devolved publishing community) we sometimes have to grit our teeth, look the other way and just recreate it.

    We’re trying to balance that with making content improvements, but when that requires sign off and stakeholder management, it’s not always straightforward.

    We’re in the business of getting all content to a future maintainable state fast so the future development gains are realised as soon as possible (can’t believe I just wrote that). It’s not about fixing every bit of content as we go. And that’s a big, nasty, bitter pill to swallow. I know that time will come, but it can’t come now.

    R.O.why?

    I think the return on investment here is huge. Working on our technical de… *ahem*… maintenance work schedule will enable us to make changes quicker in the future by:

    1. Not worrying about applying the same design change in several templates
    2. Stopping running multiple training variations across each permutation of legacy content types
    3. Not having to think about how to design that same old drop-down box or module
    4. Having a focus on one code base to fix accessibility and performance issues

    The less I say “we need to work on our technical debt” and just say “our maintenance work is needed, as it will enable us to…” then the easier this will be to grasp.

    I can measure success by reducing number of eye-rolls I get by 50%.

  • Can I borrow your homework?

    Two people studying together at a table, with one holding a notebook and the other reviewing their printed material.

    The higher education digital sector is a funny old place. I’ve met lots of people who lead digital teams from the Russell Group, from post-1992 universities and several from overseas. It’s incredible how many of them speak about the same challenges at work that I experience too:

    • Large numbers of website editors making sub-standard content
    • Procured and in-house digital solutions outside of their control that don’t consider user experience enough
    • Challenges with devolution of power across the institute, fighting against central digital policy, strategy and governance
    • Small teams spread thinly across giant portfolios
    • SharePoint implementations for Intranets being a car crash

    I’ll probably write more about those bullet points another time…

    Inspired by how, as well as what

    I think some universities handle all this really well and have found organisational models and transformation projects that have had a real impact. Take Southampton’s OneWeb and UAL’s product approach for example.

    I choose to take inspiration from these sorts of conversations and learn from how they made change work for them. However, I do know that copying them simply won’t work. There are many contextual differences between us and them – many of which I’m probably not even aware of.

    I want to bring these insights to my work, so I will add their influences to the mix when doing some hard thinking about how we can make things better. But that hard thinking has to happen.

    Blinded by the shiny lights

    But, strangely, when it comes to gathering information and getting inspiration from competitor analysis on digital solutions and features, we approach it quite differently.

    We often get caught up with what other places are working on and fixate on a desire to simply be like them. Why is that?

    I’ve heard it from across the full spectrum of roles at the University:

    “Why don’t we just have the same navigation as they do?”.

    “We need our homepage to be more like this Russell Group university”.

    “We need a course comparison feature like they have”.

    I’m all for competitor analysis. I promise I am. I just can’t face starting work on something just because someone else has it. I want to know why we need it.

    What about intuition?

    Don’t get me wrong… I advocate for using a “hunch” to get things started where lack of data exists, but when we’re picking features from other websites, we seem to be bedazzled by shiny things. We have to look deeper and understand if our hunches needs validating.

    There are some no-brainer features which we’re missing on our website. We can line up the user needs, business value and technical effort in a way that we can already see value is clear in order to prioritise that.

    But some things we can’t be so sure about. Some features simply show no evidence for adding value if we were to implement them. Also, looking around and seeing something that you already like the sound of is a classic route to confirmation bias.

    Case in point – I mentioned course comparison tools. That’s a fair bit of effort for us to put together and maintain… do users do that comparison elsewhere? What if the data we show users to compare is actually identical? Does it add significant return on investment?

    It is fine to take that inspiration, but we need to do some discovery work first.

    Fork in the road

    While it is important to learn from your competitors, it is not enough to imitate them.

    A street view featuring a red Coca-Cola delivery truck parked in front of the Colony Hotel, with a blue Pepsi truck beside it and palm trees in the background.

    We’re at a fork in the road and I need to ensure we take the right turn:
    1. Do as others do and think less about what our users need from our services.
    2. Consider more about what our users are thinking and react to that, reviewing what the competition is up to for understanding our place in the market and for inspiration.

    I vote #2.

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

  • Oh, another digital blog. Great. Here are my ambitions.

    Yes, this is another blog about digital things that you may think is unnecessary, narcissistic or just plain boring. But whatever, I’m doing it anyway.

    Some rationale

    I have been an internal-thinker-type-of-person all of my digital career. I have (I hope) provided plenty of valuable insights and thought into each service I’ve helped make and role I have had, but I tend to keep that local.

    I now want to experiment pushing that thought outwards and seeing what that brings for me personally and find out if anyone finds any use in it.

    With my PM party hat (PMPH) on, I’d like to set some sort of ambitions for this.

    Ambitions

    1. 0% moaning posts
    2. 1-2 monthly posts
    3. Make ’em laugh
    4. Care

    What does it all mean?!

    0% moaning posts

    I find myself, in particular when talking about HE digital, moaning. This fuels more moaning, which then annoys me. I do not want this to be a venting space. I want to be critical but optimistic and useful.

    1-2 monthly posts

    Look… if I say I want to push thoughts out, I will. Surely I have enough thoughts to publish monthly? I think I do, even if they’re short and to-the-point.

    Make ’em laugh

    I want this to be at least a bit entertaining. Think Sitebulb release rants with a little less swearing.

    Care

    Contrary to some people’s opinion, I really care about what I do and what digital should be. Shitty digital services make life unnecessarily tiresome and impractical for good, honest people who are forced to use them. I know it doesn’t have to be like that and I want to reflect that in what I write.