How to Get Started in Social Media for Art League City
Managing a Mobile App Development Team
1. KRISTINA PODNAR
I Can Lick 30 Tigers Today
Lessons Learned From Managing a Mobile Development Team
JBoye Philadelphia – May 8, 2013
2. I used to think as a PM.
2
kpodnar@nativetrust.com
3. Traditional project management skills still apply
3
www.nativetrust.com
Target setting
Problem solving
Leadership
Team building
Triage
Identify what is needed or has to be
done
Organize resources
Monitor performance and task
completion
Plan ahead for future requirements
Deal with any problems that arise
But mobile development is a different kind of tiger!
4. PM Skillset
4
kpodnar@nativetrust.com
Traditional PM Role Mobile Development PM Role
Plan-Do mindset
Prepare a specific timeline and
sequence of activities
Formally outline what, why, who,
how, and when
Delivering on time and on budget
are the most important things
Envision-Explore-Adapt mentality
Business need vs. technical
feasibility (variable scope)
Lead a motivated, experienced,
and disciplined development team
Focusing on delivering real
business value at all times is the
most important thing
6. 6
kpodnar@nativetrust.com
TRADITIONAL THINKING
Paced technology changes and
platform upgrades.
Greater number of
examples/proofs.
Often customizations vs.
development.
Requirements are (mostly?)
proven.
MOBILE THINKING
Marketplace is constantly changing.
Nobody has the actual solution
because you are racing not pacing
(MRAID, BlueKai, UA).
New device features are released
quarterly.
Often “on the fly” requirements.
What We’re Doing
8. 8
kpodnar@nativetrust.com
TRADITIONAL THINKING
Initiating
Planning
Executing
Monitoring and Controlling
Closing
MOBILE THINKING
More complicated environment
drives momentum and
development.
It’s a living product – we can’t
get it all in one swipe.
Any release must include an
SDK.
How We’re Doing It
10. 10
kpodnar@nativetrust.com
TRADITIONAL THINKING
Run through the system
requirements
specification.
Leverage all platforms,
browsers and devices.
Weekend/off-peak
releases.
MOBILE THINKING
Lack of specifications (SRS),
and reliance on use cases.
Improve quality before product
is complete.
UDID-based (until May 1).
App store beta cycles.
Can you really replicate testing?
How We’re Delivering
11. Key Take-Aways
11
www.nativetrust.com
Blend your PM “gut instinct” with
new thinking
Be humble about technology
Get technical
Embrace and frame uncertainty
Get a lucky penny
Go on and lick those tigers!
Verve Mobile is the pioneering leader in location-based mobile advertising. Our customers are national brand advertisers who want to engage consumers on their mobile devices with location-aware, data-driven and highly targeted marketing. We also serve premium publishers across the nation, delivering the platforms and services they need to power and monetize their mobile properties. The Verve “location intelligent” technology platform and the proprietary data it generates are revolutionizing mobile media and advertising. It enables consumer and content brands to reach their desired audiences on the go, out and about, and closer to the buying decision than ever before. Nielsen's March 2013 data release, Verve now reaches 115M unique mobile users in the U.S. The US population is about 315M people. – Nielsen Media Report March 2013
Traditionally we looked for strong PM skills and knowledge of CMS or web technologies. Technical know-how is helpful, but if you are not truly technical, it is still relatively easy to manage a team. Preferred skillsets on the mobile development side: Strong working knowledge of integration technologies Java, J2ME, Objective C and C# Strong knowledge of design patterns You can’t just facilitate the conversation, you have to lead it
Take newest features and implement them as they are released (retina, xdpi and hdpi), usually within 15 to 20 days after device functionality is released into the marketplace. Challenges presented by this approach include: Unknown requirements until device product launched (WWDC) Scramble to figure out what we need to do Scramble to figure out how to get it done – and sometimes, it is trial and error. When do you call it a failure and back off? Example: we tried to integrate native Disqus commenting within our apps, and have the comments appear without having to be logged in to the actual app. We often rely on “insider” noise about what is coming down the pike, which is a bit of a challenge in instances where you may be outsourcing and this kind of insight isn’t known. In many instances, the US market leads (ex. Samsung Galaxy III release) so you are having to facilitate the discussion with developers who get the device 2 weeks behind you. iOS devices are uniform because they are controlled by Apple. Windows Phone, which is a smaller part of the marketplace, is also consistent due to Microsoft’s control. Android devices are anyone’s guess and can perform differently from device to device. Your job is to understand a lot of the intricacies of the changes, which is a lot to ask of a lead and help often in clarifying the requirements. Also need to make certain the developers are correct in their thinking (ex. Samsung Galaxy 3 versus 4 pixels /(5-inch display with Full HD resolution). Designers need to be kept in the loop as well, which can be a challenge when they need to not only go for good design, but the myriad of different devices and permutations that can be leveraged. YuMe Pre-roll adds Other constraints: EVOLVING AND INHERENT Evolving constraints, such as bandwidth, coverage and security, currently apply to the mobile technology, but are likely to be addressed and possibly resolved in the near future. On the other hand, inherent constraints such as limited screen real estate, reduced data entry capability (due to a limited keypad for example), memory capacity, processing power and limited power reserve, are permanent, at least relative to desktop environments. We are staying ahead of the infrastructure and operations folks often, or at least in tandem. Managing for this is hard.
The most complicated environment is created when there are white labels, publisher labels, and various cutting-edge capabilities integrated. Especially in the mobile space. We tend to be agile-dominated, with a release every quarter. We understand we are never finished as we are always keeping up with the marketplace. That means: Daily scrum stand up meetings across 3 mobile development teams We independently allow Android and iOS teams to function, but we share lessons learned between them. We don’t mix platform planning meetings so as not to get “tunnel vision” For a PM, you have to get rid of the traditional thinking of initiating, planning, executing, monitoring and controlling and closing. We never close, and you are doing the other 4 all of the time. Often, we are on the cusp of bleeding edge. For example, at the beginning of the year we implemented the new MRAID standard. Only Google had gone ahead of us. Developers struggled and we had to figure out how to test while we were developing. It is a constant challenge.
For us, it is not just about mobile delivery, it is about mobile delivery in an advertising world. That means that the more details we get on users, the better our performance.
How we test and release is vastly different in our mobile world environment. No SRS because you know roughly the feature you want, but not how it will function. The use cases tend to be vague and end user focused. So the steps/process to perform an activity is often unknown. Ex. Disqus. Testing is not a simple push of content or a release into staging… We have to build the app (compile) – we use Jenkins We use TestFlight (for some things) Some things we SIMPLY CANNOT TEST Lack of automation unlike the web world. Lots of pair cording to QA in tandem Lots of guiding of our QA team to determine how to test (developer has to figure out the steps and write them out for the testers) We test as we develop – each day we compile code… if it doesn’ t compile our developers loose their bonus Our testers test every day… bugs are thrown back into the hopper If you wait to submit to store (in beta mode) you loose days Our final (final store test) has to be a UAT-quality test (final sign off by the end user) Testing of white label apps is easier. NBC-apps are harder.
Key take aways: 1) Increase your own mobile knowledge
