The Media Innovation Fellows program at UNC-Chapel Hill School of Media and Journalism places recent graduates at local media companies in North Carolina to help them embrace new technologies and respond to changing consumer needs. The Reese News Lab, managed by Professors Steven King and Ryan Thornburg, gave the fellows access to data journalism tools and encouraged entrepreneurial thinking.
Here is one fellow’s story.
Wesley Hitson is a senior at UNC-Chapel Hill, majoring in computer science. He spent eight weeks over the summer with NBC affiliate WRAL-TV, in his hometown Raleigh, N.C.
Growing up in Raleigh, I always thought of WRAL as the news channel, or at least one of them. At that point, I lumped them in with NBC, CNN, CBC, or ABC. But the more time I spent in the Reese News Lab last year, the more I came to understand how media companies function, and how WRAL fit in with other news organizations.
I learned that they were a local station, albeit a very successful one. As such, they faced a unique set of challenges. When I found out that I would be interning there, I was simultaneously intimidated and excited. WRAL was a major company, and I would have the chance to see exactly how a company of that size functions. Everything that I had learned thus far about innovation was about to be tested by a major player in the media space.
WRAL wanted to solve what they called a “data problem.” As a large company with millions of website hits per day and thousands of registered user profiles, WRAL was in a unique position: they have access to large amounts of data of a very specific group of people, namely North Carolina residents.
As the media industry evolves its practices to involve newly accessible data streams, WRAL is no exception. They wanted to build a database that would encapsulate all the data that was flowing through their servers every single day, and use that data to improve their services and the kinds of information that they could deliver their users. That was the challenge that John Conway, GM of WRAL.com, provided to me when we first discussed his biggest headaches in running the station’s digital operations. Although the specific definitions of the challenge would evolve over the summer, the challenge of collecting data would remain the central focus of my two months in the office.
Research & design process
I only had eight weeks to come up with a solution to this data problem, and I knew that part of it might involve building a database of some sort. Although I am a computer science major, building an enterprise-level database from the ground up was quite out of my skill range. Even if I had no doubt that a database was a perfect solution to their problem, I wasn’t sure that it made sense for me to be the one to make it. Would it be better to outsource that job? How else could I be useful?
Coming from Reese News Lab, I was expecting to have to do some research about what exactly WRAL’s biggest headache was. I did not want to spend all of my time there trying to put together a database without knowing for sure that it would be the best solution.
So for the first week, I took the time to introduce myself to various members of the WRAL.com management team to find out what their biggest headaches were. I heard quite a few responses, but the majority of them I could relate back to the “data problem.”
While there was so much data available to a large organization like WRAL, but they were not capitalizing on that data — sometimes they were even discarding it unintentionally. Clearly, they needed some way to keep all this information. The database was looking like a good option, but I wanted to make sure that I had gone through the requisite customer discovery process before deciding on it.
On top of this challenge, I wanted to make sure that I was not just following what I knew about the product ideation process, but that I was sharing what I knew with people within the company. After all, part of my job description was to teach human-centered design (HCD) to people at WRAL. My hope was that they would be able to spread the knowledge about HCD with their teams, and thus promote those ideas throughout the company. From the beginning, I was looking for people that I wanted to include in my team. I had my eyes on some of WRAL.com’s managing team. They reported directly to my boss, John Conway, and I thought that they would fit nicely into what I was trying to accomplish. Everyone I spoke with seemed interested, so I made a point to have them all involved. I even envisioned having two teams of four.
As I began doing my usual research, I found that I was reaching a similar conclusion to the one that WRAL had reached before I arrived. A database would definitely solve a good portion of their problems. Yet I now had to consider a new aspect of my summer challenge. This new database was an internally facing product. I was used to developing and testing externally facing products, be it for a consumer or enterprise audience; products that customers would be paying for and using. As an in-house product, this was a different situation.
I was not familiar with this position. In the Reese News Lab, the entire process revolved around going out and talking to customers to find their pain points, and then finding a solution to those pain points. At WRAL, I was working with those who would benefit from my work to find a solution. Because of this, I knew exactly what they needed because they told me. They wanted a database, and I was not able to deliver. I considered my job to be finding out that they needed a database, but it seemed that they already knew. So why was I there?
Unsure of how to proceed, I began brainstorming ideas for attracting the kind of data that WRAL wanted to collect: demographic data, and personal information. I couldn’t find anything that stuck. I was trying every single trick I knew. I was coming up with crazy ideas and I was going out and talking to people at shopping centers and malls. Nothing was sticking. WRAL already has a wide variety of products ranging from coupons to local high school sports, and they were already experimenting with new technologies like Roku and Amazon Echo. At this point, I seriously questioned why I was there and what, if anything, would I be able to produce by the end of the summer. I couldn’t make the database, and I was coming up short in all of my own pursuits.
During this period of doubt, I continued my weekly hour-long workshops on human-centered design. During my fifth week, I talked about feasibility and the importance of prototyping ideas before sending them into full-fledged production. As I talked about how NASA prototyped the lunar lander back in the 1960s in preparation for the moon landings, I realized that I needed to listen to my own advice. Instead of building out a full database over the course of two months, I would find the necessary tools and services to prototype the custom database that everyone wanted. Suddenly, I had direction again. I would prototype the database and my team would provide feedback.
I began my search by asking my team to draw out their ideal version of the database on a large sheet of paper. As they put what was in their heads down on paper, I started to notice common features that they wanted. They wanted to be able to see data visually. They wanted a searchable database. They wanted to be able to target people with relevant ads. I tallied up the most requested features, and sought out a solution that would fulfill as many of those requests as possible.
My exploration led me to a new customer relationship management (CRM) software tool, a dashboard service that could tie in with that CRM and display data visually, and a tool for automating certain tasks with “recipes”. My goal was to create a central hub where all the information was stored, and allow that information to be represented visually and be customizable in its appearance. I also wanted the database to do some things “automatically,” and that meant the recipe tool for connecting services together (for instance, every time I complete a task in our project management software, send out an email). I finally felt like I had used what I knew about design thinking to find a solution for WRAL. Find the pain points, come up with a solution to that pain, then prototype a solution.
Conclusions and results
Ultimately, my pitch was nothing more than a series of recommendations, formatted into an executable plan that the WRAL.com management could follow if they so chose. I made recommendations for the three separate services that I thought would mimic having an informational database at a fraction of the cost and development time. I was able to validate my decisions by describing the human-centered approach I took, and since I had taught the workshops over the summer, I was confident that everyone understood my reasoning. I also went through a cost analysis, and I was able to confidently advise a course of action.
I gave my pitch only a day from the culmination of my internship. I would have liked to stay longer and help implement some of my suggestions. This project had taken an unexpected turn, and I was not prepared for this change in direction. If I had considered this possibility earlier, perhaps I could have pitched sooner and then had time to help with that implementation. Nevertheless, I was proud of what I had done.
I learned several important lessons throughout my time at WRAL, and many of them have applications outside of one company, or even outside one industry. The first breakthrough I had was that any obstacles I faced that required the intervention of management or my superiors were best handled with a recommendation for fixing that issue. The managers of a major media company are very busy people, so the more quickly they can deal with an issue, the better. Instead of just presenting a problem, think through a few solutions and let them decide which they like best. That makes their job easier, and you can go into a meeting knowing that you will get a productive response.
The second lesson I learned was that major companies have more obstacles to most things than startups do. Even trying to organize meetings was difficult at times; people were on summer vacation, or had something important come up relating to their primary jobs within the company. As such, getting everyone together for a meeting was difficult at best. Even time for one-on-one meetings was short. This emphasized to me just how important it was for large companies to consciously innovate and set aside time for activities like brainstorming and thinking about customers. It just doesn’t happen day-to-day, as people easily get wrapped up in their normal tasks.
The third obstacle that I faced was hard to solve. I could only really ask the management team — who were adding this project to their pre-existing duties for an hour maximum every week. This made it hard to do the Reese-style sprint like I had envisioned at the beginning. Instead, I had to stretch my lessons on desirability, feasibility, and viability out over the course of three weeks, and even then, I had to move one of the meetings to a different week due to scheduling conflicts. This meant that it took me four weeks to accomplish what I thought would take one. Instead of me teaching a team the tools that I had learned in the past year, and then working with them to solve a problem, I found myself working alone and leading a workshop once a week. There is nothing inherently wrong with this, but it was different than what I was envisioning, and I found it difficult to complete a Reese-style challenge alone. I’m not sure how to solve this problem without some drastic changes. Perhaps future participants could have a few hours on the first day reserved with the understanding that those hours learning design thinking techniques would set them up for success as the summer progressed. I would love to see a greater number of individuals in the company be involved throughout the entire process. All in all, I thoroughly enjoyed my time at WRAL and I learned a lot about the practical applications of design thinking and innovating in a large company.