​​Fast track discovery into delivery: Research workshops

Ashley Wilden
Inside Q4
Published in
7 min readApr 17, 2023
Team members surrounding a table and talking

As the demands of a business continuously change, it is crucial for software development teams to take a step back and evaluate the best approach for adding new features to a product.

Most often there is a hidden ‘appetite’ for investing resources to solve a particular problem, and spending too long on research can mean there is no longer time to develop a solution. At the same time, spending too little can mean teams will lack the information they need to build the solution effectively.

This is where the business must balance the cost of solving that problem (whether it’s time, people, licensing costs, etc) to the perceived value that solving the problem will bring.

This article will emphasize the importance of research workshops for software development teams to de-risk complicated business or customer problems before they impact delivery timelines. This will be accomplished by covering seven tips for running a successful research workshop and sharing the experiences of conducting a 2-day research workshop.

7 tips for running a successful research workshop

Here are the top 7 tips for running a successful research workshop:

  1. Scope the time required to the scale of the problem you are looking to solve and break down the problem if it’s too large.
  2. It’s more expensive to find out something isn’t working after it’s finished. So set aside an allocation of time each sprint for research and/or success validation activities to measure progress early-on.
  3. Stress the efficiency of having all the necessary team members focused in one room for these research activities.
  4. Bring in subject matter experts as temporary participants to provide context and information for key areas of the problem you are looking to solve.
  5. Collectively determine the phases or iterations you will use to deliver value and determine how you will measure success, so that everyone on the team understands.
  6. Clearly identify the risks for the solution and include steps or tasks in each sprint as part of your research allocation. This will help you de-risk those challenges.
  7. Provide an estimate in money or time to solve the problem after it’s built out, so everyone understands the cost of the proposed solution before any work begins.

Making way for research

Encountering an issue mid-sprint is never good news. Timelines are always tight, and there is always a lot riding on each team hitting their delivery dates. When this happens, there are often thoughts of ‘why didn’t we consider this earlier?’ and ‘could this issue impact our delivery target?’, which are strong indicators that the solution could have benefited from a team-oriented research workshop.

Often the team knows what work it needs to complete in the next few sprints and has a rough idea of how it will deliver on the promised solution. Allocating time in a sprint to identify some areas to de-risk allows the team to have the opportunity to understand the nuances of a problem that may not have been clearly identified earlier.

This practice is fairly common for technical challenges and often referred to as a “spike” in the context of software development. However, the team may struggle when facing the challenge of how to approach a customer problem that has many technical solutions and requires more research to assess which solution would drive the best outcomes.

Research workshops can play a significant role in quickly de-risking complicated business or customer problems before they can impact the delivery timeline.

In the past, our team conducted broader research activities upfront and outside of the sprint cycle in order to minimize any disruptions to roadmap delivery. The Product Management team led the research with assistance from important business partners. The aim of the research was to determine the overall scope and assess the value, which would help in developing a bigger roadmap.

However, this approach did not always answer all of the detailed questions the development team would require as part of their delivery plan, especially when making progress on the plan uncovered new challenges to solve.

For our next initiative, rather than attempt to complete all possible research upfront and delay the start of delivery, we decided to allocate a smaller chunk of dedicated time for a detailed “research workshop” as part of each sprint.

This approach involves prioritizing the most critical aspects of the solution and working on them first during the initial workshop to minimize any potential risks. We would then use subsequent workshops to improve and fine-tune the solution based on the insights and knowledge gained during the development process.

The hope was that we could achieve a smooth delivery as the team would have collectively worked out the details for areas they did not understand before the next sprint and allow for any major blockers to be identified earlier in the process.

Setting the stage with discovery

The goal for the first research workshop was to understand how our customers had used a part of our product to make changes to their website, define a solution for how we could improve that workflow to provide a faster and more accurate result, and outline a plan to deliver that solution — no small feat!

We kicked off the initiative with a 2-day workshop where all team members recorded their questions on a large digital whiteboard (Miro) to gain a deeper understanding of the issue at hand and clarify any misunderstandings.

We sought to identify gaps in our knowledge and collectively discuss everyone’s questions to determine what data and feedback were needed to get answers.

Team members were then assigned to gather the required information through data, research, and reviews of previous feedback collected from the business and record their findings on the whiteboard.

Any additional research that was necessary was also conducted during the workshop, as some questions would surface many more which needed answers.

With all the data collected, the team then evaluated the answers to determine the best approach for building a solution to improve the customer experience.

Determining the best bang for the buck

On the second day, we did a quick recap of our findings and focused more earnestly on key milestones focused on delivering value quickly, while also de-risking areas which were unknown.

Using our research findings as a guide, we were able to easily identify the bigger risks to our solution and prioritize these upfront to ensure we would tackle them before investing too much time into our solution.

One example of this was identifying a part of the rollout which had too much ambiguity for us to ensure the changes we wanted to make would result in a positive experience. Our workshop allowed us to identify this risk early in our initiative delivery planning and gave us the opportunity to outline steps to mitigate the risk.

The team prepared experiments that could be run in parallel to the sprint development, helping us better understand how the rollout would work given two variations of a solution and allowing us to come back to this challenge later with a better idea of how we could iterate on our initial concept.

Additionally, we looked at which aspects of the solution would deliver the most value and prioritized these to be delivered sooner rather than later. An example of this was a simplified version of our user interface, which we could deliver quickly while we continued to add more robust functionality in later iterations.

The team wrapped up the workshop with the confidence that we could deliver a top-quality solution that met the needs of our customers and business and that could be improved over time as new feedback was collected.

Everyone’s busy. Why is this worth it?

As a Product Manager, this research workshop was an invaluable experience for our team to come together and work towards a common objective.

It saved a significant amount of time collecting and analyzing data from multiple sources, as the effort was split across members of the team who were also focused on the same goal of finding answers.

It also removed the need to have any project kickoff meetings with the squad later on, as they were part of the initial research and already understood why we were focused on this business problem.

The team felt capable of making informed decisions based on data and the technical expertise of the squad and had a plan in place for how we could handle any new unknowns in the future to avoid getting bogged down in the details.

By taking the time to incorporate the squad in upfront research activities and allocating time in each sprint for these activities when necessary, we ensured that the entire team was focused on the problem we were trying to solve. Additionally, we ensured that we could continuously leverage their deep problem-solving skills to determine the best solution for our customers and the business.

Selling the ROI of research workshops

Stopping mid-sprint to solve a problem is never good news, but waiting until there are no more unknowns will mean you never move forward. Addressing these issues before they compound through the use of research workshops and other collaborative activities means that teams are spending the time to create an environment where they can accept and plan for unknown risks while also working to deliver value to the business quickly.

The result will save time and effort (and stress!), as teams continuously engage in research, iterate on new information, and deliver an exceptional product for the business.

If you’re looking for your next adventure, explore our open positions and learn more about Q4 by checking out our careers page.

--

--

Ashley Wilden
Inside Q4

Art/Technology/Sociology enthusiast. Product Manager for Agile Dev team.