Creating a product culture at Cambridge University Press

In 2015 I was hired by Cambridge University Press to develop a web application providing digital access to over 35,000 books and 1.5 million journal articles, consolidating several smaller sites. The application would go onto have over 2 million users a day and generate £65 million in revenue per year.

It was a fantastic technical learning opportunity, but it was our culture and approach to product development that would teach me the most important lesson of all.

Our culture

I realised on my very first day that this contract would be different. Unlike every other place I had worked, everyone from the product leader, product owners and scrum master, to testers and developers genuinely wanted to help each other.

Our team was made up of people from various backgrounds at different stages in their careers. Nobody thought they were better than anyone else, with egos checked in at the door. Team members were happy to get up from their desks to collaborate together. Company politics were kept away from the team, and I was never put in any position where I had to choose a side or get involved in any kind of way.

All this made it easy for me to settle in.

Product Leadership

Up to this point in my career, I had worked with some outstanding people but not an exceptional product leader.

Vicky Drummond is what authors such as Marty Cagan describe as a great product leader. She had a passion for the product, understood the market and had a clear vision.

As well as having the skills, knowledge and experience, Vicky was trusted and loved by the team. She encouraged and supported the team to innovate and try things. Her enthusiasm was infectious. Everyone on the team wanted the product to be successful.

I would have run through a brick wall for Vicky.

Research into the market and storyboards helped us understand user journeys. Four personas were created, and every user story started with one of them, and so during planning, it was clear to the team why we were building a feature and what the expected outcome was.

Inspect and adapt

We adapted how we did things throughout the development of the product, ensuring agile was still working for us rather than being a checklist of things we had to do. This happened because the team trusted one another.

Our retrospectives were a safe place to voice concerns and issues, always starting by reading the prime directive. Paul Telford, our excellent scrum master, ensured everyone contributed and helped the team decide how to resolve problems and held us accountable for actions. This was different from many of the places where little was actually done.

Our stand-ups were more like catch-ups. We shared jokes, and it was something we wanted to do rather than had to do. As some of the team were based remotely, we organised events such as board game evenings when they came to the office in Cambridge, which created a bond between us.

Instead of the scrum master telling us what to do, he encouraged us to use our initiative and self organise. He wanted to talk less so the team could talk more.

If anybody was stuck or needed help, they used Slack to raise any things straight away rather than wait until the next morning.

We had empowerment and ownership of the product we were building.

People create a product culture, not processes

Cambridge Core was successfully launched in 2016, and I left the year after.

No other workplace has given me the same joyful experience developing a product.

I've read many books, watched talks and listened to podcasts about building a good product team. Many companies think they are doing the right thing by following a process rather than investing in current staff, hiring the right people and having a talented product leader.