Sports and Entertainment - Team #2 - Customer Persona 1
Sports and Entertainment - Team #2 - Customer Persona 2
Sports and Entertainment Team #2 - Value Proposition Canvas
Sports and Entertainment Team #2 - Business Model Canvas
Sports and Entertainment Team #2 - Environmental Analysis
Sports and Entertainment - Team #2 - Database Schema
Sports and Entertainment - Team #2 - MockUp1
Sports and Entertainment - Team #2 - MockUp2
Sports and Entertainment - Team #2 - MockUp3
Sports and Entertainment - Team #2 - Web Application Architecture
Whistle -- Sports & Entertainment Team #2
The sports and entertainment industry relies heavily on in-person interactions; fans in the stadium cheering on their teams and booing the competition, meeting players face-to-face in search of an autograph, and gathering in homes across the country for watch parties. With the recent COVID-19 pandemic and resulting social distancing guidelines, stadiums are not safe environments for fans. As a solution, we developed Whistle in order to bring the feeling of the stadium to fans at home.
The main idea behind Whistle is to provide fans with an engaging platform to interact with each other, connect with their favorite teams, and win prizes. Whistle’s main goal is to have fans predict the next action that will happen in a live game. For example, in football, fans would guess whether the next play will be a run or pass, or even an interception or touchdown. Each possible outcome is assigned a point value, and at the end of the game whoever has the most points will win a prize. Whistle collaborates with professional sports organizations to offer free tickets to a future game once COVID-19 clears and stadiums begin opening up again.
Our strategy involves partnering with professional sports teams across the country to bring our product to their fans. After all, teams know their own fan base better than anyone else and can configure the Whistle program to fit their specific fans’ needs.
Michael Boyajian (Project Manager, Senior Marketing Major @ Valparaiso University) As Project Manager, Michael maintained consistent and open communication with the team, implementing an Agile process framework to oversee the team’s progress. As a Go-team member, Michael also helped with the go-to-market strategy, market research, and the Business Model Canvas.
Chris Breuer (Website Developer/Designer, Junior Finance and Quantitative Science Student @ Emory University) Chris was responsible for user interface and user experience design and planning. He also designed the product logo, as well as collaborated on creating many of the team’s deliverables.
Sumeeth Guda (Website Developer, Sophomore Data Science, and Mathematical Statistics Student @ Purdue University) Sumeeth was responsible for some of the front end development. He also introduced the ideas of future developments for both the technical and business aspects of the product, both in the final presentation and during team meetings.
Katelyn Le (Business/Marketing Development, Senior Doctor of Pharmacy Student @ Butler University) Katelyn was responsible for the go-to-market strategy, such as creating a customer persona and evaluating competitors. She also edited the final presentation video, calendars, and summary documents for team meetings.
Dianne Santos (Pro Team Website Developer, Senior Computer Science Student @ Purdue University) Dianne was responsible for setting up the Whistle website on a MERN stack and deploying it to Heroku. She also integrated the backend functionalities, such as connecting to the Twitter API, as well as some frontend of the website.
How did you decide on this customer segment, problem, and solution?
We first thought about which customers would gain the most value by using Whistle. According to a 2020 survey from Statista, 65% of the respondents (from n=1500 person sample) self-identified as sports fans. Upon comparing that 65% to the adult population in the United States, we found that there are currently approximately 136 million adult sports fans in the United States.
Stadiums rely on their in-person events and teams rely on their loyal fans. The COVID-19 pandemic has greatly and adversely affected fan engagement across the board, having significant effects on the Sports and Entertainment industry. In a study done by ESPN, 59% of respondents stated they cannot wait to see live sports on TV again, 64% said that they now have a greater appreciation for live sports, and 78% want live sports to start up again, even if that means no in-stadium attendees. Long story short, fans are missing sports and professional teams are missing their fans.
Due to COVID-19, fans became less excited, more stressed, and ultimately, less engaged than they normally are with professional sports. At Whistle, we set out to relieve the problem of “decreasing fan engagement” in the sports world by developing a platform for fans to interact, have fun, and compete to win prizes.
Whistle’s platform not only provides teams with a more engaged fan base, but fans with a fun environment, live game updates, and opportunities to win tickets to a future live game when stadiums reopen. Our strategy is innovative, direct, and versatile. One of our main focuses going forward is to provide a more “personal” touch to our platform, configuring the site to each individual team’s specific fan base. With Whistle, the opportunities in the Sports and Entertainment industry are endless.
How did your team build and iterate on the solution?
We decided that creating a website would be the best approach to avoid hindering the reach of iOS users if we created an Android app, and vice versa. In terms of choosing to use a MERN (MongoDB, Express, React, Node.js) stack and hosting our site via Heroku, we evaluated certain factors that would best suit not only our product features, but our 5-week time constraint as well. React is fast and dynamic, which we thought would help complement Whistle’s feature of real-time question asking and answering between the user and admin. React’s dynamic feature was also perfect in terms of getting live game updates and tweets. Everything else was more so based off on our pro team’s experience with the other frameworks and database program; we didn’t want to use something we weren’t familiar with as it could waste time. Additionally, we went with MongoDB since it provided automatic Object ID’s, and we would not have to consider a great database size in this product’s prototype phase.
For coding out Whistle, we used Thomas W. Smith’s Youtube videos on setting up a MERN app and deploying it to Heroku successfully. After doing so, we had to decide on an authentication system. After looking at different, easy authentication systems, JWT seemed to be the most popular and had the most tutorials for MERN applications. We followed Rishi Prasad’s JWT tutorial and connected it to Digamber’s Sign in/ Sign up UI Bootstrap 4 form.
Setting up the project and authentication were definitely the biggest barriers for this project and once those were overcome, coding out the project features was pretty smooth. Our project manager had us create user stories, and our team met up almost every weeknight in a Scrum/Agile fashion. Chris designed mock ups that came hand-in-hand with the user stories. The mock ups and user stories helped organize and prioritize what we needed to code.
Mock data was used from a Youtube Colts vs Texans game for the live game updates and score since there weren’t any free football APIs that contained the data we needed. The fan photo slide also came from mock data image URLs since time restricted adding a profile picture feature for users. However, the Whistle leaderboard comes from real data being queried from MongoDB, and the Twitter live feed comes from real tweets from the Twitter API hashtag search. Creating synchronization between the player(s) and admin was difficult based on our desire to make it live and automatic, but we found the best solution was to create an index variable that was shared among the player and admin in order to keep track of the current question being posted by the admin and viewed by the players. A downfall of this is that the player’s page continually fetches this data every few seconds. We realize this may not be the most efficient method, but it was effective in the time we had. In the future, maybe we could implement socket.io to listen for changes in the database to avoid calling a fetch for data when it isn’t needed. Lastly, we used the UIfx library to allow a whistle sound to be played whenever a player received a new question. We found a fitting whistle sound from SoundSnap.
Online betting - database schema
Website Mock Ups - Configured to the Indianapolis Colts (Initial discussions included incorporating additional options if the user was in the stadium, such as a ticketing system for concession stands in order to avoid lines and crowding.)
Web application architecture
Key Tools, Libraries, and Frameworks
Web application (prototype can be accessed at http://techpoint-sos-challenge.herokuapp.com/)
For accessibility, if you would like to access the page as an admin, the game session password after you log in is “pacers”. Otherwise, you can click continue.
- MongoDB Atlas - We used this database because Dianne has extensive experience using it, and its free version was suitable for this project prototype. It had an easy setup and built-in features (such as automatic object IDs) that came handy for our project.
- Express - We used the Express framework to connect to the database and Twitter API. We had past experience with it, it was easy to use, and there were many available tutorials using express.
- React - React’s virtual DOM feature was a big incentive to use it. It would allow for the fast re-rendering of our pages, which was needed since the player’s screen would constantly be loading new and changing data from different sources.
- Heroku - We used Heroku to deploy our site since it was free and had fast and easy steps to do so.
- JWT - User management and authentication so users and admins can register for an account and sign in, stay logged in, and keep certain pages inaccessible based on login. Specifically, we used Rishi Prasad’s tutorial.
- Twitter API - We used the Twitter API to fetch the most recent, public tweets based on hashtags for our live Twitter feed that the player sees.
- Bootstrap 4 - We used this CSS framework since it had simple built-in elements, such as resizing elements based on screen size. It helped with the UI, especially for login and registration features. Specifically, we used Digamber’s tutorial.
- UIfx - UIfx is a sound library for playing sound effects on the web. We used this to incorporate a real whistle noise in our game, adding to the user’s experience and our brand name. We used a sound clip from SoundSnap.
See our package.json files (one in root directory and one in client folder) in our GitHub for a full list of libraries we used.
If you had another 5 weeks to work on this, what would you do next?
- Contact professional teams in the Indianapolis area
- Create partnerships with professional sports teams around the Indianapolis area
- Connect Whistle with professional teams across the country -- and ultimately -- the world
- Produce a mobile application (iOS/Android) version of the game
- Increase usage of cloud services to help handle the expected growth of users
- Utilize ML to determine fans' personal preferences. (Favorite teams, favorite sports, favorite players, etc). Then show them content based on their preferences
- Develop an AI admin to recognize specific referee commands and generate answers for the given scenario