| ♥ 0 |
Marked as spam
|
|
Private answer
This is a topic that I have spent a considerable amount of time thinking about. As a consultant, this is probably the most common question I was asked to answer, and while I hate answering a question with "it depends," there really are a few factors that determine what the best course of action in building out a UA team is: Scenario 1: We have an app that has grown completely organically and we want to start marketing it This sounds blasphemous to most performance marketers, but I think most successful apps actually start this way: the app gained traction completely organically and now the founders / executives at the company want to grow it systematically via paid user acquisition. In this scenario, I usually recommended hiring a mid-level operator who will spend the vast majority (90%+) of their time managing and optimizing campaigns in eg. Facebook, Google, etc. (versus eg. hiring a Director / VP to build out a team) The reason I suggest starting the team with an operator and not a senior manager in this scenario is that the person that joins the team will be able to add value through paid user acquisition from their first day; there's pretty substantial opportunity cost to bringing someone in who then needs to take the time to assemble a team. Also, I generally think that app-specific domain knowledge is more important in mobile user acquisition than general industry domain knowledge: there's not a huge delta between the very best Facebook marketer and a merely mediocre one, but there's a massive delta in terms of output between someone who knows the idiosyncracies of a specific app very well and someone who knows almost nothing about the app they are marketing (this is one reason I think agencies almost always underperform in-house teams). If this is the case, then an operator can learn the app just as fast as a manager can, so you don't really gain much from the manager's experience until you scale the team -- and in the case of this type of app, I'd recommend scaling the team at a conservative pace with more media buyers, analysts, and potentially infrastructure engineers and artists, with the first marketing hire being promoted to Director / VP as the team grows. Scenario 2: The founders have been running user acquisition campaigns from the beginning and want to build a team This is probaby the second most common founding scenario for successful apps, and it's a bit of a double-edged sword: it's good if there is an existing bank of campaign performance data and ad creatives as well as some basic infrastructure (eg. attribution is set up), but it can also be inconvenient for the first UA hire if the company's founders were deeply involved in user acquisition, as they tend to have a hard time fully handing that function off to someone new (read: they micromanage). In this scenario, I also recommend bringing in an operator to own the function versus a manager, with the caveat being that the team might grow faster in this scenario than in the first scenario since there is existing momentum. Scenario 3: We just raised a big financing round and we need to scale our app QUICKLY This scenario tends to be the most dysfunctional and chaotic: the company saw promising growth / engagement, raised a large round of financing as a result, and it is now under pressure to grow its DAU furiously to hit aggressive scale targets. In this scenario, I recommend hiring a senior manager, who will be tasked with simultaneously coordinating a collection of outsourcers / freelancers / agencies and building a team internally. This is administrative and managerial work, not boots-on-the-ground user acqusition, and so the principal skill the company is hiring for are time management, people management, and P&L ownership. This person should also be able to put together a credible plan that gets the company from Here to There (where there is usually a just-realistic-enough-to-not-be-delusional growth target) that they can deploy the company's newfound resources against. This person will likely lean heavily on agencies and freelancers until they can hire people to fill out an internal team, which they'll want to do pretty quickly. That's another reason it's good to fill this position with a more senior manager: they'll have a large rolodex of former colleagues from which to draw when trying to hire. Scenario 4: We are about to launch and want to have a team in place when we go live with the app (aka the DANGER ZONE) This is a difficult situation: I call it the chicken-and-egg problem with mobile user acquisition. No one wants to launch their app without a user acquisition team in place, as doing so would essentially leave money on the table if the app performs. But it's also not prudent to put a team together before an app is live -- the team won't have much work to do, and if the launch gets delayed, the team might get bored and leave. In this scenario, I actually advise companies to not hire anyone and to ask one of the founders to own this function with just Facebook campaigns until the app has proved momentum and a new hire's entire day could be filled with managing campaigns (at which point, this becomes scenario 2). There are two reasons for this: 1) if you hire someone too early and they leave out of boredom, you'll end up having to do this anyway; and 2) it's really valuable for the founders of the company to at least understand the basic dynamics of user acquisition: they'll make better hiring decisions later on as a result, and UA is so closely tied to product that understanding UA will give the founders a new perspective on the product's roadmap. Hopefully the above provides some useful guidance in making the first UA hire. What hires number two, three, four, etc. look like depends on the trajectory of the company, how quickly creative needs to be refreshed, the scale of spend, etc. Those decisions can't be made in the abstract: the company should parse out the strategic needs of the business and hire accordingly. Some more thoughts on organizational dynamics for UA teams can be found in these articles: Marked as spam
|
