Before joining Overleaf, when I was still a junior Product Manager, my product coach Simon Pearson introduced me to the continuous product discovery approach by Teresa Torres, and I was fascinated by it.

At that time most of the product roadmaps I had seen were based on ideas generated internally and often with little user research behind them. This method showed a sound way to be user-centred while reaching business goals.

Fast forward to 2019, when I joined Overleaf to establish Product Management as a discipline in the company, my new boss, Co-founder and CTO John Lees-Miller, encouraged me to practice my learnings and gradually introduce this methodology to my colleagues.

Since its early days, Overleaf has put users at the centre of its development process, so this was fertile ground for establishing a continuous product discovery practice!

In reality, most product teams see the value of product discovery but find it difficult to allocate resources to it, often ending up not doing discovery at all. In this post I’ll show you how we integrated product discovery into our ways of working in three key steps.

Step 1: Introducing core concepts of product discovery

Continuous discovery is based on a regular cadence of user interviews, where a product trio (a Product Manager, UX Designer and a Developer) observe and record user problems, desires and pain points (mind, not feature requests!) on a weekly basis. These insights are then arranged into opportunity-solution trees that are connected to product and business outcomes. Effectively, you build a map of user problems that, if solved, will also achieve your business goals—a win-win situation!

Having had some previous training in ethnographic research, my natural starting point was to get going with user interviews and invite colleagues from UX, Engineering, Support and Marketing to come along. I’d explain the method and just ask them to follow along and take some notes. We would then debrief straight after the call and produce a 1-slide snapshot that we could immediately share on Slack for everyone to see. This process started building trust on many fronts, and the concept of product trios started forming naturally.

For about a year I simply did this:

• Interviewing regularly and mapping out some opportunities into what we call here a User Needs Map.
• When we started working on a new problem, we formed a basic trio (which often was a quintet, including Support folks and extra engineers!).

We soon realised how beneficial and less painful it was to start all from the same point, rather than handing things over from department to department.

In 2021, the team that I now manage grew from 1 to 8 people, and what a ride it was! We are now a multidisciplinary team (Product Managers, UX Designers, Data Analysts) with a fantastic variety of talents and backgrounds. When people joined the team I asked if they’d be interested in learning more about product discovery methods, and I encouraged them to read Teresa’s book. Some people showed an interest in getting hands-on training so some of us went onto taking courses too.

Step 2: Putting it all together with a discovery sprint

Having had all this training, we decided to test our knowledge by immersing ourselves in a product discovery sprint for a week. We already had tons of user interview data and a well-defined outcome around group collaboration on Overleaf, so we had everything in place to give it a go.

The first step was to think about who should be involved and to what level. One of the goals of the sprint was to test the methodology and how it would sit within our existing product development process, so we invited Simon, our Engineering Director, because if he understood and liked the process it would be easier to embed it into our ways of working (spoiler: he loved it!). Our PM Roxana and UX Designer Jess completed the trio since their training was still fresh. We also invited our Customer Services Director, CCO, VP of B2C and Head of Analytics to the ideation session taking place on day 3 (spoiler: they enjoyed it too!).

We laid out a plan for the 5-day format and defined clear outcomes for each stage. Since Overleaf is a fully remote company, all of the sessions were designed with a remote-first approach (e.g. Miro boards, a dedicated Slack channel, working around core hours and with different time zones).

The format we came up with followed the steps below; the trio dedicated about 80% of their day to these activities, while other stakeholders were only partially involved:

The secondary goal of the sprint was to be able to generate and de-risk at least one idea that would improve collaboration within a group of users. Overleaf is much loved by researchers across the world as it helps them write and publish scientific papers and related documents that require input from multiple people, disciplines and roles. This is a job that all of us at Overleaf care about: it’s how our founders created the product when they were both researchers writing up papers about driverless cars!

Roxana took the lead in setting up a Miro board and spent time with Jess to prepare our opportunity map from the user insights that we had previously collected. Here is a snapshot of what she created:

Running the sprint

Day 1 was all about the opportunity map, the main goal being to identify a specific problem that we wanted to solve. We applied the “compare and contrast” method to narrow down the scope. This involves considering each top level opportunity from 4 main angles: Size, Market, Company and Customers.

Simon, our engineer on the trio, found this process liberating as it kept the focus only on solving that one problem (at least for the duration of the sprint). In this way, our brains were free to get creative.

The problem that we picked was “I want to share multiple projects with multiple people at once”, which currently affects our users when they need to get started on a new collaborative project. We all felt that this was a good problem to solve to help teams of researchers get started on their jobs quicker.

Day 2 was ideation day. We alternated “solo work” sessions and group sharing sessions, giving our stakeholders some homework and guiding them through the process. By the end of the day we narrowed down our selection to 3 key ideas: team permission administration, group folders, and tag sharing.

This day was very productive but also fun! It was good to feel connected across different disciplines around one problem, everyone contributing an important perspective.

There was a nice tension between the practical perspective (how do we build this?) and the blue sky approach (wouldn’t this be great?) and that’s exactly what we wanted to see in action!

On Day 3 we focused on story and assumption mapping, a stage that we found tricky. Story mapping the ideas (visualising how the idea actually works) was relatively easy, but we soon realised that we needed input from the people who came up with the idea in the first place. We couldn’t remember some key details and this made it hard to list our assumptions in full. Despite this, we identified some of the riskiest assumptions behind our ideas and we put them forward for testing.

On Day 4 we set up tests for our riskiest assumptions. We designed a micro-survey that we ran on social media, conducted a few user interviews and looked at our product analytics.

On day 5 we analysed the data from our tests. We were pleased to see that at least one assumption had been de-risked via the survey and through quantitative data. To de-risk “tag sharing” we had a goal to see at least 20% of respondents collaborating with multiple groups and the survey returned 70% of respondents who matched our criteria! We also found that a large percentage of our premium users were already using tags in Overleaf, so that gave us even more confidence in this idea.

We still want to do some further investigation on this, but it felt like a victory to have reduced our uncertainty on this problem while learning how to apply the methodology!

Step 3: Embedding product discovery into our ways of working

Overall, the sprint helped us test the methodology in our specific context. We experienced all the phases of the method in quick succession and were able to de-risk at least one idea. Stakeholders loved the process and this was also very important to help us create space within the company for a more exploratory approach that can benefit us in the long term.

We didn’t write any code and yet we were able to see 2 ideas fail and 1 succeed!

While running the sprint was helpful, we felt that a 5-day format was a bit too restrictive because some stages require more time than others. We also learned our lesson about clarity at the end of each stage and keeping stakeholders engaged throughout the process.

Since we ran the sprint, we started applying parts of the methodology as we need them and where we need them. Sometimes we may already have an idea in mind, so it’s good to be able to do an assumption mapping and testing exercise to tell us whether we should explore it further.

We have also created 3 separate opportunity maps, which we review and maintain fresh as we keep doing more user research every week.

The core concept of product trio is now well established and we have officially expanded this into a quartet that includes a member from our Support team.

Our conclusion is that product discovery can be part of the development process without needing extra resources or a dedicated team. We may evolve our approach over time but for now we are reaping the benefits of the methodology by embedding it organically into our ways of working.

Have you enjoyed this post? We are a friendly bunch, get in touch if you have any questions or want to hear more!

---

About Overleaf

Overleaf was founded by two mathematicians who were inspired by their own experiences in academia to create a better solution for scientific collaboration and communication. Now we are a team of about fifty based mainly in the UK, Europe, the US and Canada. We were recently recognised as one of the UK's top 100 fastest growing businesses and as the Best SaaS for Nonprofits or Education in the 2020 SaaS Awards Program. Our vision is to be the go-to place for writing scientific documents.

• Join our team!
• Want to take part in user research? Book an interview.

About the Author

Roberta is Product Director at Overleaf. She has over 15 years experience in STEM Publishing in various roles across marketing, business and product management. She has worked closely with authors and researchers to understand their pain points and loves making their lives easier! Originally from Italy, she lives in London and has a passion for making hats. You can follow her on LinkedIn and Twitter.