Esportscall

This discovery process started when we tried to figure out how we could help grow and make the esports landscape more organised. As being organised is a good baseline for growth for an industry, in turn making it easier to step into the industry. Having years of experience and working closely with both broadcasts and bringing tournaments (professional as well as amateur) to existence. Below I have detailed the discovery process for a possible new web platform between tournament organisers and broadcast talent.

This process took place between February and April of 2021.

I would already want to thank my team lead at the time who helped me through parts of the process and my peers, who helped me in some of the ideation. Whenever I mention a "we" in this documentation, it will be either my lead or peers who helped. I have tried to be as explicit as possible to show when I pulled others in.

First we figured out who exactly we would like to approach. Our target market for this discovery was Tournament Organisers (going forward shortened as "TO(s)"), who often also organise (or outsource) the broadcast of the event, and Broadcast Talent (going forward usually named as "Talent(s)"; commentators, show hosts, casters and any other on-screen artists). Later on we also figured out that the latter category could see growth with additional categories (like statisticians, who provide stats to be displayed on the broadcast, freelance league administrators, etc.).

I started with user interviews with both TOs and Talent. For this, I first created a template set of interview questions. Starting with an icebreaker and some general demographics questions, funneling down to questions about what their biggest problems are that they are facing with their work. In general the interviews lasted from somewhere between 30 minutes to 1.5h. I conducted 9 interviews in total (4 with TO representatives, and 5 with Talent). I found all the interviewees by approaching contacts from my network.

User interview questions.

User interview questions.

It was a deliberate decision to skip creating a survey and trying to angle for a large general data set. Firstly, because fishing for a big enough data set would have not been as easy, because it is quite a niche target audience. Secondly, because we already had found a direction, and a possible gap that we wanted to explore. The communication between TOs and Broadcast Talent.

The interviews were conducted online. I recorded the interviews as audio or video, depending on what the interviewee was comfortable with. This helped in being later able to re-listen to parts or check for any possible behavioral cues. Furthermore, this gave the option for my team lead and peers to see how I worked and for them to be able to give feedback.

Alongside the recordings, I also actively took notes during the interviews. I must admit, it would have been a great benefit to have had a second person in the interview. One being dedicated and paying full attention to the interviewee and being able to catch cues and direct the flow, whereas the second person could dedicate themselves to taking notes.

All the upcoming information is sorted on a Miro whiteboard, which happened to be one of the better free whiteboard services at the time of going through this discovery process. The information on most images is not intended for reading, but rather as a visual aid to show the process. 

One of my philosophies when making drafts is that they should be understandable to anyone who looks at it with minimal explanation. This is why some of the information might be laid out in a hectic way but, hopefully, understandable way. I feel it saves a lot of time if you know you want to quickly find connections between information and that there's a high possibility that you need to move information around. In the drafting phase I always want to stay as flexible as possible without losing integrity of the information.

Back from the tangent! After conducting the user interviews, I started to arrange the notes from each interview I conducted, as follows:

I laid out the notes on the whiteboard. On the left you can see the legend. I color coded each interviewee (top to bottom in the legend on the left are: first 4 are TOs and the following 5 are Talents), and added their notes to the board, showing connections with parts of their responses. I would have loved to do a sentiment and theme analysis, but I felt the notes were thorough enough to be able to start categorising them. These notes mainly show the user pain points or topics that they felt very strongly about.

Next up, I first sorted the piles into related topics and pain points between the interviewees. At first, I thought it might make sense to organise the TO and Talent notes separately. This did help in that I could see what were the biggest problems for both groups. However, it quickly became apparent that I should connect the pain points between the groups.

From these clusters we were able to write out user problems (or needs). Blue is the needs of the Talent, and green for the needs of the TOs.

The clusters also help to see how much a topic was discussed, but we learned that it didn't necessarily mean that it was the "best" problem to solve. By "best" I mean the most urgent or most impactful for both groups. However, the big clusters did give a good indication of a general direction.

Next, we pulled all the problems/needs we wrote out of the note clusters. We talked through each of them, trying to give them a ranking in priority. Where priority is the impact for the groups and a perceived do-ability when it comes to developing a solution.

We also tried to give themes for each of the problems/needs or a cluster of the problems/need (marked with the transparent boxes next to both of the ranking columns).

From this we also got a general sentiment on what the goals for both groups currently were. Those clusters being shown on the far left and far right of the above image. We only used this as an indication of a goal for both of the groups, rather than a hard truth.

From the ranking, we identified and decided to go with three "big" user needs according to the priority we set in the ranking. All of the user needs from the ranking were worth a consideration, but this is the direction we chose: trying to focus and narrow down what service we are able to offer and to keep in mind that each need will take significant time to develop. For each group.

From the ranking we created an opportunity tree, with the prioritised user needs. We brainstormed a vision and north star, giving us even more direction. Even though both a vision and a north star SHOULD come at a later point, we felt we had a good direction and already a clearer picture of what direction we could head towards. This is the point where we figured out that we would like to develop a platform/market where we can connect TOs to Talents.

Then I gathered 3 peers to ideate on how to solve each of the user needs. You can see each idea of all three of my peers color coded, with a legend for who contributed each idea. For this brainstorm, I asked each of them to do it by themselves, as to come with ideas on their own. And then invited them to share their and talk through their suggestions in a group. My own ideas are marked in red.

I then clustered ideas where possible, and wrote each of them out. You can see that on the yellow notes.

More ranking! I talked through the ideas with my peers. How they should be prioritised, what ideas would make sense in the bigger picture, and which ideas should be cut and would not work or would not be necessary for the product to function.

We also identified some additional points that should be kept in mind when we get to development. These are marked in red.

This whole exercise gave us a general user flow for an MVP or the absolutely necessary needs that should be met for both groups, and how the needs between the groups are connected.

This is where most of the initial product discovery process ends. The upcoming parts are more musings or could be considered to be part of what developers do. But since I only had access to a small group of people and I needed every proof possible to show the feasibility of the product, I also worked on the following parts.

A brainstormed version of a full user flow. The purple notes are all the possible actions a user will be able to take. Again, green is actions for the TO, and blue are actions for the Talent.

(Below) User personas. 2 Talent user personas, 1 TO user persona, and 1 for a tentative Talent Manager persona. The last one was created as an exploration into a role, and is not part of the MVP. I wanted to mark this here as an avenue for growth and further options for development.

Persona-centered user actions. What/how/why actions they need to take to get to the desired outcome. Blue for Talent, green for TO.

Detailed tentative sitemap of the platform, with the actions users are able to take.

Condensed tentative sitemap of the platform.

Extended list of actions, fields, information that is needed from the user or how the user will interact on the site.

A click-through prototype of the platform in Figma.

Below you can see a high level view of what went into the pitch deck. The pitch deck consists of 20 slides and the planned time for the presentation is 45 minutes. This includes a projection of the costs, development time, and revenue. The calculations were done in a separate file.