Context

Elsevier is a global data and analytics company that also offers many healthcare products for doctors, nurses, patients, and many other kinds of clinicians to ultimately improve patient outcomes. The PatientPass product specifically helps hospitals and organizations give their patients relevant medical education to keep themselves healthy.

The PatientPass team had been working non-stop for two years to deliver the MVP, which had been defined years prior. With a renewed company focus on innovation, multiple leaders of the Product and Tech teams expressed interest in coming up with innovative ideas for our product and giving the team time to experiment.

The Challenge

The Product Lead, Tech Lead and I knew that we had to find a way to fit specific time for innovation in without disrupting the development work for our upcoming product launch deadline. We also knew that we wanted the team to have autonomy over what they worked on and we wanted everyone to have some fun and get a break from day-to-day work. 

How might we engage the team in innovative thinking in a time-effective way while simultaneously providing a framework and room for autonomy?

Next Steps

My solution was to run an “innovation sprint” that spread over several months to accommodate ongoing development work without major disruption, featuring a kick-off workshop that would take advantage of the team being in the same office for a few days.

For the kick-off workshop, I gave a presentation that discussed the concept of innovation and went over the schedule and goals of the sprint. I then led a brainstorming session to generate product-adjacent problems to solve and encouraged my colleagues to form groups around the problems they found most interesting. Our four teams then spent the afternoon working on problem statements and solution generation. I hopped between groups to provide coaching on the process and potential additional activities they could do.

Over the next two months, I met with each team individually to help flesh out their ideas and clarify what they were working on. In the final week, I met with each team to further clarify their projects and helped them schedule dedicated hack time that complemented their regular sprint work. The teams really pulled together to find ways to solve their problems within our existing application.

We had a reveal at the end of the week, in which teams presented their problems and solutions to stakeholders and received very positive feedback. Ultimately we had three projects that identified applicable solutions - one that could potentially be a quick fix that we could implement and two others that provided initial explorations to elaborate on in the future.

The last step, as with many good sprints, was a Retro to discuss what the team liked and thought could improve about the innovation sprint.

Outcomes

The innovation sprint was deemed a huge success.

Besides having three great ideas to incorporate into our product, the overwhelming feedback from the team was that they had a great time, which was one of our key desired outcomes. We also received very positive feedback from our Product and Tech stakeholders.

This was the first “innovation” sprint in our product division, and possibly in the entire company. We used a modified version of this format to run two additional innovation sprints in the fall of 2020 and the spring of 2021 and the format has gone on to be used on other teams as well.

Project Challenges

Teams were not co-located

At the time of kick-off, our team was in the office and our remote team members were in the office for a visit, which was perfect for that initial meeting. After that, however, it was more difficult to meet and work on concepts together. Having everyone together on the first day was probably the highlight of the sprint and it would have been great to at least bring everyone together at the end as well.

Balancing autonomy and guidance

We wanted the team to have autonomy to choose what to work on, since they had been heads-down on product delivery for so long. However, it was hard to find the sweet spot between encouraging innovation and independent problem solving and preventing the team from working on a feature we were already planning on. A lot of the problems that were proposed were either extremely narrow or extremely big and I found myself suggesting additional problems to solve. For the next innovation sprint, I reviewed the different kinds of innovation (sustaining vs breakthrough vs disruptive), which seemed to help with this problem.

Quality Engineering wasn’t sure what to do with hack time

In our retro, QE members expressed that they were not sure what to do when the team was working on developing their idea. I later spoke with QE on ideas on what to do about that in the future.