As a digital project manager at Viget, Ryan Schaefer has led a variety of projects including custom CMS builds, conversion analytics sprints, iterative design systems and native app design and development. In this guest post, he shares tips for successfully managing a native app build. Read on for insights, and catch his session at the 2019 Digital PM Summit in Orlando, this October 21–22, for a better understanding of best practices, responsibilities and core duties.
This October, I’ll be speaking in front of my talented peers at the Digital PM Summit in Orlando. I’m almost too excited about it. My topic is on project management for a native app build—specifically, some of the differences in constraints and expectations, the unique mindset you should adopt, and the heightened importance of traditional core PM duties.
Below are some high-level tips and teasers for navigating these challenging topics.
But first, some context: My D.C. metro-based agency, Viget, offers development, creative, user experience and data services. We have taken on too many project types to enumerate—my role as a project manager is to lead client services, cost and time management, product ownership and ultimately drive the project forward. It goes without saying that each type of project calls for flexibility within these areas, in both how you plan for them and the tactics you take to execute. I found this to be especially true with my first native project, a 23-week Android build for a well-known D.C. startup that has a suite of intricate and popular software, data and media products.
Before you go on an adventure like this with your client, keep these things in mind:
Set expectations early for timing
Native projects are typically larger and more expensive, which means the stakes are higher. Everyone is on the same team and working towards the same goal, but it’s especially important to be mindful of timeline and budget in these situations—things can quickly spiral out of control.
As such, being transparent about risks, feedback cycles and planning around PTO and holidays is imperative. If you’re on the same page as your client every step of the way, there will be no surprises.
Prioritization becomes crucial here as well. Once you’ve gone through definition and planned out your milestones, take some time to identify which features, functionality, designs or animations should be the first to go if you end up in a tight spot. Share it with your client—they’ll be appreciative and could help rearrange priorities, which will make long-term decisions easier.
Rely on your team
This doesn’t mean you shouldn’t become as familiar as possible with the brand, product, its architecture and the design logic. And it doesn’t mean there aren’t real ways to help facilitate critical thinking about key decisions. If anything, it makes it more important so you can communicate internally on the same playing field.
It does mean you should be proactive about asking questions, particularly ones that will help inform decisions you need to make as the PM—things like what to focus on for weekly sprint planning, identifying potential roadblocks that could throw a wrench into the timeline and addressing those early and when to cut certain features when it becomes clear they’re no longer viable. As is normally the case, collaboration is important.
Chip away at the expectation that static designs need to be 100 percent approved
This is a big one. Things will just look and feel different once they’re in your hands. It’s that simple. Muscle memory and years and years of navigating through apps and browsers on our phones have trained us to act and feel a certain way. Unexpected behavior is magnified.
In my experience, you can get about 90 percent of the way there on some design approvals. Working to get approval on the last 10 percent comes with a disproportionate amount of back-and-forth, and often doesn’t result in any real decision. That’s where you and the client should both understand it’s impossible to exactly define how something should work until there’s a prototype, so trying to reach a consensus during the concepting phase can have diminishing returns and not be cost-effective. In a weird way, designs are almost never 100 percent approved. And that’s okay.
Set up a rolling QA and continuous integration process as early as possible
Continuous integration helps limit unnecessary back-and-forth amongst your team. Big and complicated apps call for very involved quality assurance testing—constantly disrupting your team to ask for a deploy is a recipe for delay and frustration.
This is not normally something PMs can set up by themselves, so stress the importance of this with your developers and work with them early to set up the process.
Know what the developers are thinking about and what’s putting stress on them
These are a few more points outside my realm of knowledge, but they’re certainly things you need to be aware of as a PM.
Kotlin, a popular language for Android development, is like Javascript, Swift and Typescript, but it’s not exactly the same. It provides developers features to help write higher-quality software.
A browser is more forgiving. A lot of errors on Android apps will crash the app—that cost of failure is very high.
Native apps are written in statically typed languages, which require a more formal way of expressing ideas. This helps to avoid bugs, but makes edge cases painfully clear. A viable solution in Kotlin might require thinking through 90 percent of a problem, whereas you can often get away with only 30-40 percent for a JavaScript project.
Clients’ APIs can be complicated, antiquated or not make a whole lot of sense. That makes integrating with them much more difficult, but it has to be done. Finding solutions to that doesn’t often call upon a developer to write better code, but rather to write code in a very specific way that may not be intuitive.
There will be development implications that have to be considered for successful design, and a successful project
The web has less constraints than native—rather, designers and developers are operating with what are standard conventions, instead of protocols.
But for mobile, material design, systematic controls and expected flow dictate a lot of how you need to build and use an app. For example, what do the system buttons on your device do within the app? What happens when the user is offline? These are questions that typically don’t need to be answered for traditional web builds, but are standard practice for apps.
As a PM, you should look to involve your developers as much as you can in the design phase. Often, they’ll be able to point out when something can’t or shouldn’t function as it’s been designed.
My main takeaways are that building and designing for something complicated is a fantastic way to hone your skills (even soft skills), establish strong relationships with a (hopefully) understanding client team as well as your internal team and diversify your company’s service offerings.
Consider the suggestions above and make sure you handle your normal day-to-day PM operations as you should, and you’ll be looking at a successful native app project. Then go grab a beer when you’re done, because you’ll probably need it.
If you have any questions or comments about PMing native apps, drop me a line here, on Twitter, or you can get in touch with Viget.
Image via Viget