8746306102_7b993e7899_b

Intranets are products, not projects

Here at Intranetizen two of our most frequent rants are over the low value that businesses frequently ascribe to their intranet and the people who work on it, and the constant cycle of intranet  relaunches and declines. 

But arguably both of these issues stem from the same cause: the tendency to view intranets as projects.

The intranet-as-project phenomenon – whereby teams are given an unrealistic budget and timeline to deliver something – means that intranets often fail to meet expectations, attention quickly turns elsewhere and the intranet is left to go stale until the cycle repeats itself in five years. Too often, companies plough resources into an intranet or ESN programme, only to de-resource it the moment it goes live, effectively wasting much of their investment.

This means they often don’t deliver the expected business value, and end up being seen as a cost centre rather than a value-generator for the company – in turn impacting on the standing the team delivering the intranet have internally.

Great intranets deliver a ‘long wow’ rather than a big bang, constantly developing to add new services in response to user needs and business objectives. So they’re not projects but digital products, constantly evolving in the same way that an app or good transactional website does to keep up with changing demands.

By labelling them as digital products we help shift the mindset away from the big bang and toward one in which intranets continue to evolve to meet changing business needs, so they deliver clear business value in the long term.

A complex intranet – like a complex website – could easily be seen as a number of constituent products.

What does that mean for intranet managers?

In the digital industry it’s increasingly common for this process of evolution and iteration to be spearheaded by a Product Manager. This role is sometimes described as “the CEO of the product”, with responsibilities such as:

  • Representing the user and conducting user research
  • Engaging and managing stakeholders
  • Prioritising the development backlog
  • Liaising with technical teams
  • Managing day-to-day running of the product
  • Input on marketing the platform to build adoption and use

The essence of product (and intranet) management

Product Managers come from a variety of backgrounds. They don’t tend to code, but they have a strong enough technical understanding to be able to effectively translate between the business and development team.

Sounds familiar, right? There are clear parallels between this and the responsibilities that intranet managers juggle.

Inviting the comparison – maybe even labelling ourselves as Intranet product managers – may help those with responsibility for intranets to get remunerated properly for their unique mix of skills, too.

Many of our readers report their role is graded as equivalent to an internal comms manager  because of its position in organisational structure, despite intranets requiring a completely different – and much rarer – skillset. Conversely, Product Manager is a relatively senior role and well-paid within a development team, with clear career progression as they take on more leadership responsibility (for example to Head of Product). Choosing a better-understood job title could make it easier for those who have delivered intranet products to move into other digital roles.

Lead the revolution

Our teeth are immediately set on edge when we see recruiters advertise for Intranet Project or Programme Managers.  We’re continuing to champion the intranet as an evolving business tool, and we believe labelling them as products – and the people running them as product managers – will lead to better platforms, and better recognition for the people who deliver them.

Here’s some resources on product management that might help you make the case for shifting to a “long wow” product view of your intranet:

Have you had success having your intranet seen as a product? We’d love to hear your experiences in the comments below.




There are 5 comments

Add yours
  1. Luke Oatham

    This has been a particular problem that I’ve seen in government intranets. Unfortunately, it’s encouraged by a central promotion of agile project methodology and intranets tend to get lumped into the same bag as designing digital public services. I’ve seen “intranet redesign” projects that tick all the government service design and agile methodology boxes, many a blog post touting user-centred research and iterative development. All well and good until the project ends. Then the intranet becomes just another entry in a contractor’s CV as they move on to their next agile project. And the intranet gets redesigned a year later.
    I work with a group of government departments using the same intranet platform, which is regarded as a product. It’s ongoing, under constant development and evolves with changing needs. It doesn’t have a delivery date. Departments feed into the development of the product roadmap and new features and updates are rolled out to the group.
    Something you mentioned, that often gets forgotten when the intranet is seen as a project, is the needs of the people who will manage the day to day running of the intranet. User research tends to focus on the front end user, but content publishers are users too.

  2. John Scott

    I totally agree with looking at Intranets as a products. I think that more and more people recognise that the project phase is just the start, and they talk about road maps etc. However, I think there is still a lack of action in that 1-2 month period after a launch/re-launch. That’s the time when something really needs to happen, in order to establish the pattern of continuous improvement. If you wait 6 months it is just too long.

  3. Rebecca Jackson

    Great post Sharon, thanks for writing this. It was a few years ago when speaking to a friend who is a Product Manager that I realised that product management was what I was practicing. I’d struggled early on in a large project to get the business to understand that I was not IT and I was not the Project Manager. I think it will help many more intranet people to look at themselves via the lens of product management. A new way to look at intranet “projects”, and a new way to look at our roles.

  4. Dorje McKinnon

    Sharon, you’re bang on. For a couple of years I’ve seen product manger jobs and seen the similarities. Thanks for making it clear to the entire intranetizen audience.
    If we as a professional group can help change the organisation mindset to intranet/digital workplace as product I believe we’ll have made a substantial difference to the quality of the workplace all our staff inhabit.
    Thanks for the great post.

  5. David Hobbs

    Thanks for writing this post — I agree that teams should look at their intranets as products rather than a series of projects.

    A couple years ago I wrote a book on this topic: Website Product Management, Keeping focused during change https://www.amazon.com/Website-Product-Management-Keeping-focused. The title says website but it applies to intranets as well.

    In my opinion, one of the key roles of the product manager is to make as high impact changes as possible, especially by trying to make as long term and broad changes as possible. And one of the keys here is that there should be a recurring cycle of getting input from stakeholders and devising a work program that’s less frequent than agile cycles (see https://davidhobbsconsulting.com/how-to-articles/cadences-digital-presence-change).


Comments are closed.