Transforming a museum through product management

Lucie Paterson, Australian Centre for the Moving Image, Australia


Drawing on the recent successes of the Experience & Digital Team at ACMI, this paper will explain how the team is using product management methods to strategically transform the organization’s culture from one of irregular, exhibition-driven change to one that is constantly and continuously evolving. Using Simon Wardley’s Pioneer Settlers Town Planners concept as a framing tool, this paper will discuss the first year of a new process implementing product management practice and conclude by giving a series of recommendations able to be adopted by museums large and small. 

Keywords: user experience, product management, strategy, digital transformation, disruptive, innovation


The Australian Centre for the Moving Image (ACMI) is Australia’s national museum of film, TV, video games, digital culture and art, located at the heart of Melbourne in Fed Square. Its mission is to enrich our lives and foster our creative industries by illuminating the moving images and technologies that define our age. Director and CEO Katrina Sedgwick says in order to meet this mission:

“ACMI celebrates and explores the moving image—and in this rapidly evolving sector must become an organization that is constantly evolving itself. The challenge for us is to build an internal culture that is resilient and risk taking, active and accountable to ensure we not only remain relevant to our visitors and communities but stay ahead of the curve in content, process and delivery.” Sedgwick (2016)

Like the digital products we build, we want the museum to exist in a state of perpetual beta:

“The idea that there is an endpoint to the change, a desired future state that can be achieved after which everyone goes back to their day-jobs seems increasingly old-fashioned in this perpetual beta world … to re-invent museums we must also create a culture that is biased towards doing new things rather than towards the past.” Carding (2015)

To achieve this, new museum staff were brought on including CXO (Chief Experience Officer) Seb Chan. Seb leads the newly established Experience & Digital Team that works across the entire organization, continuously improving the visitor and staff experiences of ACMI’s galleries, customer touch-points, technology and systems through a rigorous focus on user experience and human-centered design. The small team of our developer, product manager and recently added content producer work on multiple products at a time, bringing in colleagues from other teams depending on the business aim and the nature of the product.

“My friend Matt Locke says companies have a dominant tempo. Fashion brands work around seasons, publishers on editions, and tech companies in sprints. If you come from a different discipline, like digital design, there’s a good chance you will clash with the dominant tempo, and get rejected.” Budd (2016)

For museums, the dominant tempo is exhibitions. This is what makes museums resistant to the structural change that many are trying to achieve.

Project management vs product management

Museums have a history of running projects, particularly exhibitions, in a waterfall fashion, following a PRINCE 2 (PRojects IN Controlled Environments) version of project management. The methodology was inherited from the UK government and has been passed on through the public sector and nonprofits in the UK and internationally. Because museum funding in Australia relies heavily on the government funding model, the sector has been tied to this way of project procurement and delivery.

My former work at Southbank Centre in London showed that using PRINCE 2-based project management to deliver digital products didn’t have a track record of success. In 2014, we initiated an ambitious series of projects called the Digital Transformation Programme. Two years were given to develop a new website, a content model for the arts sector, and fundamentally re-engineer many of the internal systems and infrastructure. Much of the project was about automating processes and integrating systems which on reflection were not to meet identified user needs. The program of work had several interdependencies and the projects were never realized. For digital products to be successful, they require a process that puts users first.

In Wiggins (2017), Shetler asserts that at Britain’s Ministry of Justice (MOJ), where Shetler was chief digital officer from 2014-2015, there is a “clear understanding” that internal systems serve the end users. One person, Tom Read, is in charge of both digital and information services … Shetler wanted his team to concentrate on delivering services for “the user”—not the government agency they worked for, and encouraged them to watch people interact with websites. But everyone, Shetler says, “underestimated” what it would take to make change happen in Canberra.

At ACMI we are using product management methodologies that put the user first and allow products to be delivered more nimbly. When using project management for delivery, requirements gathering is done first—typically with internal stakeholders only. There is a fixed scope, budget and timeline and a detailed specification that must be met. Across the three museums and arts institutions in my career, only a handful of projects successfully delivered what was agreed at the outset—the quality of the product tends to be sacrificed to get the entire scope delivered, the budget blows out, or timelines aren’t met. Following launch, the project gets handed to an operations team to run day-to-day and there’s no plan for evolving the product to meet new user needs. At ACMI the previous website project didn’t launch with the publishing dashboard and an alternative solution was never delivered. That meant that distributed authorship was delayed for over two years. The website’s performance also suffered because as new features were added, there wasn’t time for testing and refining the speed of the site and no budget was allocated to allow this work to be done following go live.

Product management, on the other hand, mitigates these risks by keeping the decision making as close to the end user as possible. Essentially what you are building is responding to changing needs. It’s the cross-section of business, technology, and user experience. Product management is about adding value to the business, knowing how to get something built and being the voice of the user inside the organization. Its approach considers the whole lifecycle of a product from researching the market and users, setting the vision, managing the design and build, and then testing and evaluating to inform further iterations. The origins of product management can be traced back to 1931 when brand man Neil H. McElroy at Procter & Gamble interpreted the “Brand Man ethos” as the product manager being the voice of the customer in the organization and emphasized the importance of always putting decision making as close to the customer as possible.

To identify user needs at ACMI we use a mix of service design methodologies, observational and ethnographic approaches, combined with motivational segmentation of our audiences. ACMI worked with Morris Hargreaves Mcintyre to understand our audiences and Meld Studios to understand their behaviors through user journeys (Chan, 2016). Using these methods has told us a lot about our visitors and also revealed many new expressions of internal user needs, too. Because our team sits as a horizontal unit across the institution, we’ve been able to make observations across the organization and identify common user needs and behaviors across teams and departments that were not understood as being shared.

Pioneers, Settlers, Town Planners

Simon Wardley’s approach to Value Chain Mapping known colloquially as “Wardley Maps” places user needs as the fundamental first step in any product development. Wardley (2015) writes that “it’s important not to think of your needs—for example, your desire to make a profit or be successful. You need to think carefully about what the user actually wants.”  From a background in technology, Wardley recommends that to allow for continued evolution of a product, instead of splitting the organization up between ICT, Marketing and Finance, a more effective approach is to consider the different roles and working styles required within an organization. These are described in three broad groups: Pioneers, Settlers, and Town Planners. Each group has a different set of work practices and contributes in different ways to the overall business. A smaller business such as a startup would operate often at the Pioneer/Settlers end, but a museum with all the different outputs arguably would benefit from a structure that supports and is comprised of all three. The diagram beloq maps each group against the lifecycle of a product. It illustrates the relationship between the groups, what their competencies and attitudes are, and which group is best placed to manage the product or service at each stage of its life. Key to this model is the constant evolution of a product or service over time—Wardley’s approach forces a consideration of time and movement.

Figure 1: Simon Wardley’s “Pioneers, Settlers, Town Planners, and Theft” model. Settlers steal from Pioneers, Town Planners steal from Settlers and then Pioneers steal components from the Town Planners

Budd (2016) describes each group well:

“Pioneers are great at innovating new products, getting them to beta, and figuring out product-market fit. Their mantra of ‘move fast and break things’ doesn’t always work at scale.”

“Settlers excel at spotting new opportunities, nurturing them, and getting them to scale. Most new companies are started by pioneers, but it’s the settlers who make the ventures successful.”

“Town planners are the department leaders and operations teams; the design researchers, dev-ops specialists and QA teams. They bring a level of rigor and practice to what was once the Wild West, providing structure, dealing with governance, and supporting the entire ecosystem.”

All the groups respect one another and understand that to meet user needs, and for the product and ultimately organization to succeed, they are all necessary but need to let go of the product or service when the new user needs require transition onto the next phase.

As a museum, we’re in the business of using storytelling to narrate our ideas and collections to offer meaningful experiences to our visitors and communities. We look at the past and present but also explore the future. We’re a place where people of any age can learn, experiment, and ask questions. We therefore need to spend our resources wisely and channel them towards developing experiences that meet our mission. That’s why as a team we encourage colleagues to interrogate the rationale for doing something to ensure it meets the museum’s goals and our users’ needs. We use commodity services wherever it makes sense to give an excellent customer experience without having to take on hosting, upgrades and maintenance tasks, which is what you would get with building a bespoke product. This is so that we can spend time adding value to our visitors’ experience.

Getting past the Not Invented Here Syndrome

The biggest challenge working in this way, and common to other industries as well, is the Not Invented Here Syndrome present in teams across organizations. Museums are not exempt from this. This occurs when teams reject suitable external solutions to software development problems in favor of internally-developed solutions. Nash (2004) explains it as such:

“Not Invented Here Syndrome is the tendency of a project group to believe it possesses a monopoly of knowledge of its field, which leads it to reject new ideas from outsiders, to the likely detriment of its performance.”

Museums often customize or build their own solutions to problems that are already solved. Apart from obvious examples around IT systems such as ticketing and donor management, and, to an extent, collection management, a clearer example exists with museums’ engagement with Wikipedia. Many art museums have historically been very reluctant to contribute artist biographies to Wikipedia, preferring to write and host their own. Yet from the perspective of the general user, Wikipedia will be the obvious first port of call and that time and energy would be better spent improving Wikipedia and working on other projects.

In the digital space at ACMI it’s played out in different ways. The first is when a staffer has been trained to work in a certain fashion and takes a lot of pride in what they do—a different solution contrary to their training and thinking doesn’t sit well. Some teams feel that because there’s a whole team available to work on a single project, why wouldn’t we continue to build on something in-house rather than try an alternative solution. It also happens when a significant investment has been made in developing a product or service, including staff training and documentation. In this context, it’s hard to understand the rationale for sacrificing the resource in favor of a new solution. At ACMI we focus conversations on the user needs and finding the quickest and most cost effective way to meet them. It’s always a decision about using new or different technologies versus the cost of getting an existing system to a place where it can be the solution.

When the product gets to the town planners it’s been embedded in the fabric of the organization for some time. It has been integrated with internal systems and interwoven into the technology stack. It’s stable, and everyone is sufficiently trained and familiar with it. While that’s a necessary part of the process, it can be an impediment when new user needs are identified. That’s when some of the components need to be taken back by the pioneers and revised to meet the changing user needs.

To turn the museum into one that is constantly evolving, that addresses the needs of our users at every step, we need to review the structure and change the tempo, and arm our colleagues with the right tools, skills, and confidence to continue making this evolution possible. I will now discuss how we have disrupted the town planners at ACMI with four products—an audio guide, the online shop, a long form Web page, and the new ACMI website.  

The arrival

When I joined ACMI as product manager in March 2016, there was a large backlog of work that had been in a queue for some time. It was diverse in size and ranged from minor website coding changes to moving the shop online and finding a solution for an organizational calendar. It was all diligently listed in a Trello board but needed more detail and clearer priorities. The first task was to sit with our Developer Andy Serong and other programming and marketing colleagues to understand the depth of the tasks and their importance to our visitors. The Trello board was only being used on a daily basis by Andy and I—we used it to prioritize work and manage the workflow. Seb primarily sourced the information he needed from the Slack channel which pinged all changes made to the Trello board. The primary content editors of the website sat in the Marketing team—they were members of the board, but didn’t engage with it, even to get a sense of the work. Instead weekly meetings were held with marketing to talk about the next week of work and communications were done on e-mail.

Seb had rolled out Slack six months prior and it was in its infancy, with 65 people reading messages and half of that writing them. Seb was running sessions with staff and the take-up was good, but it wasn’t integrated into any workflows and people were figuring out its use. Our team used Slack for all group communications and any new conversations were had through it to initiate other teams. To reduce use of e-mail and the number of meetings, and to increase transparency and collaboration, we were keen to get the entire organization using Trello and Slack for multi-team work and to start giving preference to public channels over private ones. The best way to do this is “learning through doing” and a one-person-at-a-time approach. This would allow our colleagues to experience the benefits and then sing the praises of the tools to their teams. In March, we moved offices across the road from the museum to a new co-working space, ACMI X, which is a five-minute walk from ACMI. Slack was integral to this move, making communication and working between buildings more efficient and manageable. The move was significant, as it marked a line in the sand between past work practices and new work practices—an immense amount of change was about to begin.

The maiden voyage

The first product delivered by the team was an audio guide for the Scorsese exhibition which opened in May. It used interview material with director Martin Scorsese talking about objects in the exhibition. Visitors accessed it over ACMI’s Wi-Fi on their own device for free. For previous exhibitions, like Tim Burton, Game Masters, Star Voyager and William Kentridge, we offered paid audio guides in addition to entry tickets, the latest in 2012 being run off an iPod Touch. Since then we’ve observed increasing numbers of visitors on their phones at the museum and we liked the idea of them consuming our content on their devices—something that would add to their ACMI experience. The thought of asking them to juggle another device felt cumbersome, and our visitor services colleagues often reported that the operational piece that came with devices was a headache for them and disruptive to the visitor journey.

The exhibitions and curatorial teams had seen success with audio guides and the exhibition came with pre-recorded audio guide content, but we didn’t want to lock ourselves into an audio guide system. We’d seen the rent or purchase services like Antenna International being disrupted by lighter weight app and Web based audio guides such as MyTours, and were watching what other museums were doing in this space. Plenty were experimenting with Web apps—The Met, MOMA, The Whitney, and our neighbor National Gallery Victoria, to name a few.  

Earlier project teams had delivered for the needs of a previous type of museum visitor, but the solution didn’t seem to meet the user needs of today. For example, we didn’t want to lock up the content to the device because we knew that it had value beyond the exhibition. This has been attempted by others (see Chan and Cope, 2015). We had a hunch there was an appetite for visitors to return to the material following their visit—perhaps on their tram ride home. We also didn’t want users to have to download an app in order to experience the content either. Many institutions have identified this as a serious barrier to the uptake of museum apps. (See Lewis, 2014).

As a small team, we didn’t want the ongoing technical debt for upgrades and managing assets that comes with using a CMS or app-building service through rent or purchase. It wasn’t to be an integral part of the exhibition visit, so we also didn’t want to spend a lot of resources on something that our team would find hard to maintain, especially when its overall success was yet to be proven. We also needed to be realistic—there were only three weeks until the exhibition opening.

The stable solution the “Town Planners” had built didn’t meet the new user needs of being able to experience the content outside of the museum. We took it back to the “Pioneers” so that we could evolve the notion of the audio guide into something smaller and cheaper, that met the needs of the user and that we could support. At the outset we didn’t know if it would end up being an audio guide—this allowed us to experiment and develop the idea along the way. We decided to create our own theme for the Jekyll static site generator as a template for building lightweight audio guides. This produces a set of HTML files that can be hosted almost anywhere.

The audio guide was hugely successful, with 38% of visitors experiencing it while at the exhibition. The feedback was that it was simple to access over the free Wi-Fi, the onboarding was straightforward, visitors liked that it was free on their own device, and they enjoyed the personal touch of Martin Scorsese leading them around the exhibition.

The static HTML media guide model has since been adopted by MyTours, and our code has been forked by Minneapolis Institute of Art, Melbourne Museum, and Vila Itororo, for an architectural tour in Sao Paulo. AMCI will continue to explore this approach, evolving the code base if user needs and circumstances align.

Finding our sea legs

Shortly after the success of the Scorsese audio guide, we put the museum shop online. It took just four weeks and cost $AU 5,000. The online shop was a fully functioning public-facing prototype, and it was important it didn’t result in hours of staff time maintaining the platform when it might not be fruitful.

At its most basic level an online shop is made up of three components—an inventory system to manage the products on sale; an interface for customers to select products from; and a payment processor to securely process credit card payments. Shopify bundled these under one single monthly fee. Some colleagues felt we should look at unbundling these because the museum already has a payment gateway solution and a potential inventory system with Tessitura and wanted to custom build the front end of the site.

Online retail is well serviced by a range of commodity solutions which also offer the ability to heavily customise the design and user experience. Given the stability and user expectations of online retail, it would be foolish for a museum to consider building their own e-commerce solution. By picking Shopify, we handed over the responsibility for updates and maintenance to a third party, trusting the platform. And the monthly Shopify fees are far lower than the combined staff hours paid to run and manage an in-house e-commerce solution—thus it was manageable for our small team.

One alternative that was considered was to go with what the organization already had which was Tessitura—an e-commerce solution optimized for ticket sales rather than the sale of retail products, and integrate it with our finance system Epicor. Whilst Tessitura had been successful for ACMI for ticketing, to tailor it for online retail to support our product range would have required significant bespoke customization which would have had spillover effects on the broader ticketing solution. Integrating it with the finance system would not have made it easier for prospective shoppers to select and purchase with us, and therefore wasn’t meeting a user need. Often current stability can get in the way of what your customers actually require, and for the online shop, it was a no fuss way to purchase a retail product.

Because we’re a museum and not in the business of developing (or running) e-commerce platforms, or resourceful enough to host and secure our own on-site solutions, we went with Shopify, which gave us a way to quickly and cheaply realize a high fidelity Minimum Viable Product (MVP).

We experienced the Not Invented Here Syndrome with our colleagues during this project—first with the choice to use Shopify instead of Tessitura, and then when choosing MailChimp for e-mail marketing over Wordfly, which already comes with a deep Tessitura integration and is used variously across the organization.

Extending this further

Late in the piece we had the opportunity to run the end-of-year donations campaign through Shopify. Similar to how Cooper Hewitt sells theirs through their online shop, we wanted to try this to reduce the barrier of entry and number of clicks from seven with TNEW to three. There was some back of house manual entry to be done to process the purchases, but because these tasks don’t result in added value to the business or meet a user need it’s something that just needs to be done.

The online shop has been a success adding a new revenue stream for the museum. In terms of reputation, putting the shop online has been beneficial for our brand, and the donations campaign has been our most profitable to date.

If we’d not been driven by user needs, the internal requirements would have eventually outweighed them and we would have spent months agreeing on the project’s scope. Instead we got an MVP up and running that could accurately assess and validate the needs of our users. Adding the end-of-year donations campaign would have been seen as out of scope and would have required a new project to look for a separate donor system that could cater to internal stakeholders.

At the launch of the shop we added a Slack channel which pings every time something is purchased. This reduces the amount of reporting required and puts emphasis on the importance of the shop (and donations) for teams that might not engage with the commercial side of the museum.

The third leg

In September we presented Del Kathryn Barton: The Nightingale and the Rose exhibition. It included objects, videos, drawings, and animations from the creative team (including artist Del Kathryn Barton, filmmaker Brendan Fletcher and animators Method Studios) and revealed a behind-the-scenes of the short film of the same name.

The team knew that ACMI’s website was insufficient for meeting latent user needs around exploring exhibition content in greater depth before or after their visit. We’d been watching long-form journalism become mainstream and were inspired by what Walker Art Center were doing with their Superscript online magazine ( We were fortunate that the exhibition curator was willing to trust us and try something new. Given that we were restricted with the current website, we decided to create a product with significant post-visit value for visitors and educators, instead of presenting it on our website in traditional form as merely a “visitor attractor.’ This meant putting the entire exhibition online in a single, long-form style page.

For a positive user experience, long-form articles require different typography, image sizes, and browser width video. Our existing website at the time was too unwieldy and did not allow for flexible layouts with fluid content. Building a new template wouldn’t have met the new user needs any better, plus we wouldn’t have been able to explore new potential ideas for pioneer work. Also making adjustments to the existing website would have been extremely costly and time consuming. We looked externally at solutions for the cheapest way to champion the new user needs that would help deliver our mission of increasing digital literacy and visitor knowledge about screen culture.

We found a product called Shorthand that is similar to the audio guide, in that it publishes to static pages. It meant we didn’t have to pay a developer to write a new theme or template for our existing website, and we didn’t build something with WordPress or another CMS that would require long term upgrades. It’s important for one-off exhibition microsites to be as static and as “set and forget” as possible, so that we don’t increase the number of legacy projects to maintain. Shorthand makes it simple to change the style of section, add media, and edit. Colleagues got excited for what might be possible with the new website.

If we’d used the existing infrastructure and built a new template in Umbraco it would have incurred considerable bespoke work, involving great cost and time, and no significant improvement to the new user needs.

The long-form model was a success ,with users spending on average six minutes on the extended webpage. For past exhibitions, users had spent between one and two minutes browsing. 10% of visitors made it all the way to the bottom of the page, which confirmed our thinking that there is an appetite for content presented in this way.

The last crossing

What the Nightingale exhibition, long-form, and Scorsese audio guide demonstrated to our staff was that the existing website was not able to deliver the new goals the institution had for digital engagement. Technically, we were facing a costly and time-consuming upgrade from the existing CMS, Umbraco 6 to Umbraco 7, which would have involved considerable rewrites. User experience wise, the site was suboptimal—it was difficult to find out what was on, the breadth and depth of our program wasn’t communicated well, and there were too many dead ends, making the discoverability of related content difficult for users.

There were also some critical internal timelines at play. We had recently launched an internal brand refresh whose core values were vastly different to how ACMI was represented on the website. A new film program and pricing structure was due to be released on Boxing Day (26 December), and the site needed to be competitive with other cinemas and represent films in a way that both film-goers and film distributors expect.

The previous CMS Umbraco had been selected because it was built for a locally hosted Windows environment. This is where our ICT team’s skills, interests, and training ran deep. Since the Umbraco website had been built, it became embedded in people’s knowledge and workflows. There had been training, manuals created, and technical documentation produced, but we knew it was not going to meet the new user needs.

Philosophically though, as a museum, we aren’t in the business of building websites and managing hosting. Instead we are in the business of delivering great content to our visitors to help meet our mission. The approach we took was to outsource the design and development, but ensure the project was a co-design and that the skills of internal staff were developed, seeing us take on more responsibility over time. We partnered with The Interaction Consortium and have used their open source CMS for museums called GLAMkit. Our Developer, Andy Serong explains GLAMkit:

“Technically, it’s a collection of packages built on top of the Python-based Django framework and Django Fluent CMS with custom Events and Collections packages. IC have done the hard work of nutting out common requirements for galleries and museums, so a huge benefit of going with them was that we didn’t need to design our overall architecture from scratch, we got to inherit a lot of solutions and prior knowledge.”

Using GLAMkit also opened the door to future opportunities because of the new architecture. It will also be in a better position to serve new user needs that are still unidentified, and it also meant that we could spend more time on the ACMI specific requirements of the long-form pages, Works, and Ideas.

Long form articles

Being able to build long-form pages like we did for the Nightingale exhibition was a key outcome of the new website. In GLAMkit we are able to build pages using a number of different types of content and then move the order of them. We can now create events, articles, and pages using a serif font, include image, video, quote, links, call to actions and image gallery blocks, and add Google map and social media embeds. All are fully responsive, working beautifully across devices.


Every film, game, or artwork we screen or exhibit at ACMI now has an associated Work—it’s like a collection object or artwork in other institutions. It means we will have a complete record of everything we’ve shown in the museum and when. Because we’re a museum of the moving image our “collection” is really one that you watch, so this is a way to document it, make it public, and include data from other sources, like directors and cast from The Movie Database or link to the film to watch on Netflix.

Online magazine

The addition of Ideas was the other strategic shift we made with the new website. It’s a magazine-style section with video, podcasts, and articles discussing the reason behind our mission and program—why we screen what we screen and exhibit what we exhibit. We wanted this to be at the heart of the new website. It combats the issue the old website had in that is allows users to discover more content so there’s never a dead end.

Project approach

Our approach to the project was a little unorthodox. Our brief explained the issues with the current website in full. We listed the key outcomes—mobile first, reflecting the brand refresh, showing the breadth and depth of the offer, calendaring, ability to produce long-form content, and that we are a museum that has cinemas. We described our desired technical stack in terms of cloud hosting and an open source CMS, stated how we wanted to work, and, skill wise, where we wanted to be in a year.

Early in the process we identified the core user needs. They account for the 80% of our visitors — with a slight skew towards newcomers/first-timers:

  • A visitor that knows when they are free but not what we have on at that time;
  • A visitor who knows what they are interested in but not what ACMI has to offer them;
  • A visitor who has heard about a particular event and wants to find out more about it.

There are other visitors—students, teachers, corporate partners, sponsors and job seekers—but we were determined to not get sidetracked by the 20%. Otherwise you end up trying to build a site for everyone and end up servicing nobody.

We said that working in a transparent and open way was important to us, and invited the successful candidates to work with us in our co-working space, ACMI X. We wanted to ensure we were user testing at different stages of the project and emploing agile ways of working, so we were collaboratively sketching wireframes, prototyping, and testing rather than arriving at the end of the process with a surprise big bang reveal.

One month on from launch and it’s been a success. Andy is already able to make code changes and manage his own deployments; our team and ICT have access to AWS and can analyze server load when the site is running slowly amongst other things; we’ve got 63 users in the CMS, half who are are regularly creating and editing events and pages.

The engine room

As soon as we lifted the lid of the old website to understand the content publishing workflow and how tickets were built and put on sale, we found it to be inefficient, with no transparency in the process. There were two Word documents our programming colleagues completed to get an event onto the website with tickets. They sat in a folder on our internal server that couldn’t be accessed off-site or on a mobile device. Communication of where these were, and then a discussion around this, was done over e-mail, pulling in entire teams. For a product to be a success, the systems and processes that are working behind the scenes also need to be addressed.

In Wiggins (2017) Paul Shetler states the DTO was supposed to improve “the front end” of digital services—websites. But good websites depend on all kinds of other things, including back office systems. One of the lessons certainly worth learning is that it’s not enough to own part of the service: frankly, you have to own the whole service.

Trello and Slack had proven to be powerful tools for getting content to automatically pull from one system to another, so it was a natural transition to move to the same model for event publishing and ticketing. The aim was to eliminate double entry which increases the likelihood of human error and wastes time. We wanted to improve transparency of the process so that anyone collaborating could see the workload of the teams involved and the status of their job. This would mean reduced phone calls and e-mails and less meetings. It would be the central place for all communication about the job, and could be accessed outside of the network at home or on your mobile phone.

We built the event pages in GLAMkit to include a “Send to Trello” button, and the fields that are required for the ticket build process are pulled into a Trello card on a dedicated “Event ticket build” board. Additional information such a GL code, holds, and session times from our space booking system are then added. The card is then assigned to the ticketing supervisor and is dragged through the workflow in full view of all board members until the event is ticketed and ready to be published by the Web team. We can all see the size of the workload at play and what the status of individual jobs are. All additional information, attachments, and communication are on the card and the full history is listed.

For events and pages to be reviewed before publishing, GLAMkit lets us assign them to a colleague, and that person gets a Slack notification when there’s something for them to review. We’re still in the early days of this process, but already the transparency has brought out issues that would normally have been hard to identify when conversations were happening in many different places—over e-mail, the phone, and in person. Now it all lives on the Trello card.

Figure 4: process for getting tickets for events built in Tessitura and published on the website

Increased digital literacy in the museum

The majority of people across the museum are now using Trello for cross-team processes. All staff are on Slack, with almost 200 members, plus external partners that we are collaborating with on projects. Our colleagues in marketing log website issues on a Trello board and sit with our team one day a week. This almost eliminates the need for meetings. All communication with them is done over Slack, and this is the same for most staff in the organization.

In addition to promoting digital literacy to our public, we need it to be high for our staff, so that teams are empowered to update and own their own content and contribute to the ACMI brand, which is part of the museum strategy. For these new processes to be successful and to spread the product management approach across the museum, all teams need to be digitally adept. There have been challenges getting the new processes up and running—some staff have been at the museum for 15 or more years and their ways of working are engrained. When a new way to approach a problem is suggested, it can be hard to get by, because it’s seen as yet another thing to learn or another account to login to. Weisberg (2016) explains the importance of digital skills for a museum:

“It’s more than just tech training. Museums and staff have to be responsive and open to shared practices and understandings of what it means to be technically trained in museum work. Digital literacy is a cultural shift, not just knowing how to use a couple of programs. That’s what will let digital departments, and the technologist staff members sprinkled elsewhere around the museum, spend time on the amazing projects only they can do, and not just supporting their colleagues. Better tech skills all over the museum lead to a better workplace environment for all.”

In conclusion

Applying Wardley’s model as a way to look at how digital products have been delivered has enabled us to see better ways to innovate and experiment with new and emerging technologies that meet the museum’s mission and the needs of our visitors.

The delivery of each product has also revealed a series of unmet internal user needs. This process of “learning through doing” has allowed us to implement new tools and technologies to solve workflow, process and task management problems, and introduced staff to new ways of working to improve collaboration, transparency, and productivity, spreading the practice of product management across the museum.

Teams are starting to more closely interrogate why they are doing things, why they are working the way they are, and asking if there are better ways to approach issues. User needs are being considered earlier on in conversations, leading to better solutions to problems and increased opportunities.

As new staff join ACMI, they are initiated into these new ways of working. The tempo of the organization is changing into one that accepts a state of perpetual beta and constantly evolves. Next stop exhibitions.

A series of behind-the-scenes stories documenting the process and the rationale for all products and processes described in this paper have been published on  


I would like to give a special thank you to Seb Chan, Andy Serong, and Jessica Bram for their support and advice to collate this paper. And a wider thanks goes out to all the staff at ACMI for coming together over this period of change and embracing the philosophies discussed in this paper to help to change the tempo of the museum.


Banfield, R., C.T. Lombardo, & T. Wax. (2016). Design sprints for teams. O’Reilly Media, Inc. Consulted January 31, 2017. Available

Budd, A. (2016). “A model for Digital Transformation: Pioneers, settlers & town planners.” econsultancy blogLast updated September 12, 2016. Available

Carding, J. (2015). “Changing Museums.” CODE | WORDS: Technology and Theory in the Museum blog. Last updated December 9, 2015. Available

Chan, S. (2016). “Visitor journey mapping at ACMI. ACMI Lab blog. Last updated December 15, 2016. Available

Chan, S. & Aaron Cope. “Strategies against architecture: interactive media and transformative technology at Cooper Hewitt.” MW2015: Museums and the Web 2015. Published April 6, 2015. Consulted February 1, 2017. Available

Earle, E.W., & R. Bruce. (2004). “Pictures and People: Distributed Query Database Collaboration.” In D. Bearman & J. Trant (eds.). Museums and the Web 2004: Proceedings. Toronto: Archives & Museum Informatics, 2004. Last updated March 25, 2004. Consulted January 31, 2017

Eriksson, M. (2015). “The History and Evolution of Product Management.” Mind The Product. Last updated October 28, 2015. Available

Hellmuth, E., S.F. Fantoni, T. Leason, & J. Mayhill. (2016). “A seat at the table: Giving visitors a voice in exhibition development through user testing.” MW2016: Museums and the Web 2016. Published February 2, 2016. Consulted January 31, 2017. Available

Lewis, A. (2014). “What’s it like for Museum visitors to connect to Wi-Fi on a mobile phone?” Victoria and Albert Museum blog. Last updated May 4 2014. Available

Mann, L. & G. Tung. (2015). “A new look at an old friend: Reevaluating the Met’s audio-guide service.” MW2015: Museums and the Web 2015. Published February 1, 2015. Consulted January 31, 2017. Available

Mannion, S., A. Sabiescu, & W. Robinson. (2015).An audio state of mind: Understanding behavior around audio guides and visitor media.” MW2015: Museums and the Web 2015. Published February 1, 2015. Consulted January 31, 2017. Available

Mannion, S., A. Sabiescu, & W. Robinson. (2016). Innovate or stagnate: Disrupting the conventional audio guide.” MW2016: Museums and the Web 2016. Published April 2, 2016. Consulted January 31, 2017. Available

Nash, M. (2004). “Overcoming ‘Not Invented Here’ Syndrome.” Last updated April 12, 2004. Available

Pichler, R, (2010). Agile Product Management with Scrum: Creating Products that Customers Love. Addison-Wesley Professional. Available

Serong, A. (2016). “GLAMkit and switching technology stacks at ACMI.” ACMI Labs blog. Last updated December 23, 2016. Consulted January 31, 2017. Available

Wardley, S. (2015). “An introduction to Wardley ‘Value Chain’ Mapping.” CIO. Last updated March 19, 2015. Available

Wardley, S. (2012). “Pioneers, Settlers and Town Planners.” Last updated June 4, 2012. Available

Wardley, S. (2015). “On Pioneers, Settlers, Town Planners and Theft.” Last updated March 13, 2015. Available

Weisberg, R.J. (2016). “The Event Horizon of Digital Skills and Museum Staff.” Robert J Weisberg Blog. Last updated August 16, 2016. Available

Wiggins, J. (2017). “Why Malcolm Turnbull’s digital transformation guru Paul Shetler had to quit. Australia Financial Review online. Last updated 27 January, 2017 at 4:00 pm. Available

Cite as:
Paterson, Lucie. "Transforming a museum through product management." MW17: MW 2017. Published February 1, 2017. Consulted .

Leave a Reply