Idea generation and development was a topic that I found particularly useful. As marketing majors, we have to come up with campaign ideas or promotion ideas for products or services all the time. There have been times we’ve had to come up with product or service ideas, but usually these were just tweaks of what already existed. With this project, this was the first time we actually had to figure out what kind of service to offer, what the service would provide, and what the service would solve—all from scratch. We weren’t given a template, but we were given steps. First, we had to figure out the problem that the segment we wanted to target faced. Since we didn’t know what our company was, we didn’t really know what specifically to look for. Through traditional and projective technique we found that our segment of newlywed couples with professional degrees and jobs found it hard to do all they wanted to do in their busy day. They loved trying new things, were pretty settled in their careers, and spent much of their time on Facebook. Second, we had to take what we learned and begin figuring out how we could solve their problems. Without knowing much about what kind of product we should be developing, we started coming up with ideas. Once we were told what our company was, we had an easier time narrowing down our options. Here’s where the development part comes in. In the past, when we’ve generated new ideas for projects, they’ve all been pretty rough. We would get the basic idea down and hope that in the real world whoever takes on the project would develop it more. That was not the case with this project. Since we actually had to create a prototype (versus just a description of the idea), we had to be as specific as possible when creating a physical version of our vision. We actually had to sit through and think about what we wanted to offer and if we would actually be solving a problem by this offering. We then had to think about the practicality and feasibility. We had quite a few ideas, but when we evaluated them on a practicality or feasibility scale, the service just didn’t make sense. For example, we thought it would be cool to have an app that told users about deals near places they drove by to make their shopping for efficient. This would require the user’s smart phone to be GPS enabled and speaker settings to be on. Since there may be many times that our users may not have GPS enabled or have their phone on silent, developing such an app didn’t seem practical. Once we narrowed down our idea to exactly what we wanted based on how it served our persona’s needs and its feasibility and practicality, we had to further flesh out the ideas to make sure that it worked in terms of usability. We then had to think from the company’s perspective. Would this be a feasible plan for the company? How would the company make money? Finally, after we had our prototype designed, we went to our segment to ask their opinion. With their input we improved our prototype. By having to delve into the details we went beyond just coming up with an idea. We created something that is pretty close to being finished. The idea generation and development gave me an understanding of all the little pieces needed to create something realistic. I now understand that just coming up with the idea isn’t enough. One has to develop the idea for it to actually mean something.
A tool that I found especially useful was the empathy map. Prior to idea generation and development, we had to get a good understanding of our persona. By breaking down our persona into Think & Feel, See, Hear, Say & Do, Pain, and Fear, we could better analyze each aspect of our persona. Granted some of our points were redundant, but by getting a deeper understanding of how our personas saw their world, what they felt, and what they wanted, we could better serve their needs. The empathy map served as a guide in the development of our research as well. Though in past projects we had done a general analysis of our segments, the empathy map allowed me to delve deeper than I’ve ever had to before and get a more realistic idea of what our persona’s life was like.
Even though the project was ambiguous, there was a clear flow from one step to another. I felt that each part of the project—persona, research, problem statement, rough prototype, and final prototype—were all necessary. Of course in each individual phase of the project we had to provide what we learned and any problems we faced. I personally did not feel that this was relevant at all. At least in my group, we focused more on the actual phase of the project than the reflections. As we did the project, we came up with problems to put on the reflection slide. However, we never referred back to it. I feel that instead of making the reflections slide mandatory, it should have been optional. This way groups that had questions or problems could put those issues on the slide, but other group wouldn’t be forced to waste time creating questions or problems just to fill up space on the slide.
The insight/experience audit and prototype project was probably the most ambiguous project I’ve ever had to complete. I think its lack of structure was what allowed my group to exercise our “creative juices.” However, I remember being very frustrated with the ambiguous nature of the project. I like structure and concreteness. It is very difficult for me to work on something without knowing what the end is supposed to look like. Other members of my group were way more comfortable with ambiguity. They taught me to take things one step at a time rather than constantly worrying about the end result. As with any group project, coordinating times for everyone to meet was especially difficult. We often found ourselves completing the phase report at the last minute. It was frustrating to have to rush through the phase report because of our schedules. I felt that Professor Walls provided really good feedback to help us tweak our rough prototype in order to make it more feasible. Without his help, we would have had some issues with our business model since we were depending on ABC instead of Belo Corporation to partner with Facebook. I wouldn’t say this was the most enjoyable project that I’ve had to complete, but it wasn’t the worse. I feel that if I had a product/service I was more passionate about and if my team didn’t have just a difficult time meeting, I would have enjoyed the project more. Regardless of our scheduling conflicts, I feel that working with my team helped me better enjoy the project. Like I said earlier, my team members actually helped me handle the ambiguity of the task at hand. I think I would have had a harder time without them.
