Due to the nature of the project, the process work isn’t public. This post is instead dedicated to general reflections from building a product from concept to launch.
During the summer of 2014, I was hired by Gannett, a large media holdings company that owns USA Today, for their pilot Fellows In-Residence program. I was placed in a team of four people, and our goal was to come up with a brand new product concept for millennials, support it with a prototype, business plan, and research, and pitch it to the company’s executives.
We ended up pitching a mobile networking app concept called Favour, a product that was centered around getting and making introductions for new contacts. The executives found our vision and product promising, and we got approved for further development towards an initial launch. Our team worked remotely with a development firm and launched February 2015.
Gannett gave us only one real requirement for a new product concept: a millennial target audience.
Our driving vision for Favour was to give college students and young professionals, who tend to face a lot uncertainty about their futures, a better tool to navigate ambiguity by introducing them to the perspectives of individuals who have gone down similar routes as them. Professional networking to us appeared to be a very specific instance of how people tackle this inherent uncertainty, and we felt there was a place to improve how networking was traditionally perceived by a lot of millennials: forced, transactional, and awkward.
We explored a large handful of various ideas throughout the process, and functionally, our team behaved similarly to how a very early-stage startup would. We all got involved in research, user testing, fieldwork, and designing, and we were given a great deal of independence to execute our vision. The whole process of building Favour was itself an exercise in navigating complete uncertainty—creating something from nothing—and we all took away plenty of lessons.
Below are a few insights that I personally learned.
Much of the early stages of Favour were dedicated to validating high-level ideas, and a lot of time was spent on ideating and gathering feedback on various situations and models. Our early focus wasn’t on app-level interaction details, since our primary goal was to justify to the executives that there was a worthwhile business opportunity and a potential solution.
The prototype we ended up presenting was built relatively quickly and was far from refined. However, it was an effective demonstration of our overarching value proposition and identified breakdowns in what our team considered a flawed professional networking process. As a result, the executives saw potential and approved our pitch.
After our team got the green light to develop the product, there was a natural raise in expectations for the project. Sam Altman writes about this phenomenon well in a post about the difference between projects and companies:
Projects have very low expectations, which is great. Projects also usually mean less people and less money, so you get the good parts of both flexibility and focus. Companies have high expectations … this is a company, not a hobby, and you need to do something that sounds like a good, respectable idea … The risk of seeming stupid when something is just a project is almost zero, and no one cares if you fail. So you’re much more likely to work on something good, instead of derivative but plausible-sounding crap.
While Favour was not a company, the tonal shift before and after our pitch is similar to the distinction Altman draws here between projects and companies. After the pitch, more parties got involved to build the concept out to fruition, along with an assumption that the prototype we pitched was the idea we were going to refine and build out.
At the time, I wasn’t explicitly questioning whether the current prototype was the one worth refining. I had this nagging feeling that the total solutions space could have been explored more before the pitch, but after we got approved, there was a sort of implied acceptance that we would refine the current idea.
I personally was intimidated at the idea of bringing up radical new directions at this stage, but objectively speaking, the cost of having a conversation is much cheaper than committing engineering resources. Most likely, we wouldn’t pursue new ideas, but at worst, they could end up with new insights to apply to the current prototype.
Perhaps the trickier concern is learning how to get past local maxima, but I find that’s an issue that can only be solved by going through a volume of work.
The big caveat for this point is to balance smart refinement with an aggressive need to move quickly. Work has an uncanny ability to fill up the allotted time set aside for it, so it’s important to be vigilant towards the goal of getting a product or feature in people’s hands once a strong hypothesis is formed.
At least not in the early stages.
There was one particular idea that resonated with our group in the early exploratory phases but part of the reason we shied away from it was that it was being done well by another organization.
I admittedly felt a natural urge to be original, but in retrospect, all successful companies have built on existing ideas. As our group later looked back on our work, we started feeling that the amount of approaches in the space, similar and different, merely validated that we were working on the right problems.
In the early stages, it’s perhaps more important to get behind an idea the team is passionate about regardless of whether it’s been done before. How the idea is executed would give it a unique and distinct life of its own, so it matters little how many seemingly similar ideas there are.
Throughout the process of building Favour, we presented to a lot of different individuals, so the term millennial was practical for succinctly describing our target audience. However, its usage also bled over internally as our team thought about and explored various ideas.
I have to be honest with you—I'm not a fan of the term. As a millennial myself, I rarely hear the word used in a candid conversation with other friends, and the amount of writing on the subject has lent it a lot of connotations that are useful in some situations and not in others. For me personally, I found the word encouraged a sense of otherism. We ourselves were millennials but by using a term that is commonly used by non-millennials, there was this subconscious effect of distancing ourselves from that specific demographic.
Being able to step back is necessary for assessing an idea objectively. Applying empathy is a very natural part of the design process, and similar to social situations, it serves specific purposes in varying doses. However, when creating a product for ourselves, we also need to be able to become the user. In that situation, I question whether the term millennial was the best way to talk about the product and experience.
This point might be a seemingly minor rant on semantics, but I also don’t want to underestimate the subtle and pervasive powers of language. Language is essentially an interface between thoughts, and the specific words we use come loaded with their own individual connotations and subtext that color the way we think about a specific problem.
Perhaps the main takeaway here is simply to be aware of the framing effects language can have on how a team thinks about the product experience and leveraging those different perspectives to best dissect a problem.
One of the main aspects of Favour I personally found successful wasn’t even the app itself—it was a curated blog of interviews we collected from mid-career professionals on how they got to where they were. The blog was a part of the content strategy behind the launch, and it was in a similar spirit to one of our earlier product ideas.
At the end of the day, the actual app we created was one specific tool that could make the challenge of navigating professional uncertainty a little easier. However, very often, the ecosystem that a product belongs to defines the experience more for the people using it than the actual product engineers and designers work on. I think the big takeaway for me is being aware of the natural tunnel vision that can occur when you’re designing and being able to step back to examine the broader environment the product fits into.