Tips for Project Managing a Native App Build

This article originally appeared on viget.com.

Building a native app is hard work. They require specific languages, tools, and architecture setups that veer from traditional web hallmarks. They also require a different way of thinking, more from a development and design perspective, but also in certain areas for project managers.

Here at Viget, we’ve done a few native app builds. I’ll be speaking to my experience on the largest we’ve done to-date (more info on that to come soon via case study!).

Below are some key takeaways I have after running this 23-week Android app build for a well-known DC startup that has a suite of intricate and popular software, data, and media products. This project, which has additional technical complexity from traditional web build projects, showed me how important these PM skills are while you, your team, and your client go through this journey together.

Set expectations early for timing.

This is a good practice for any project, but especially with a native build. They’re typically larger and more expensive, which means the stakes are higher. Nobody, not a client, a vendor, an executive, or any involved party, wants to see an end product delivered late. Everyone is on the same team and working towards the same goal. 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 feature 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 also makes your job easier. It’s always better to know here than to guess.

Rely on your team.

They know much more about what they’re doing than you could hope to. That 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 and how to convey that to the client in a practical way. 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 differently 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 making a too-early decision during the concepting phase on that last 10 percent usually means everyone is spinning their wheels. In a weird way, designs are almost never 100 percent Approved™. And that’s okay.

Get batched feedback.

Native development is challenging — especially when integrating with a complicated client API, as is often the case. I was very fortunate on this project to work with a great client-side Product Manager who was the consistent voice for anything and everything. It was a blessing.

That doesn’t usually happen. Large investments like this are often influenced by a steering committee, multiple executives who may not be as familiar with the product but have strong opinions, people from different departments with competing agendas, some combination of the three, or more complicated situations beyond this.

Conflicting requests can be a nail in the coffin. So how do you mitigate them?

Sadly, there’s no one way that always works. Your best bet is to reinforce during the early project planning stage that a singular voice that can distill feedback from multiple parties within their organization, and suss out inconsistencies with an eye towards the goal of the product, will be immeasurably helpful. Put the onus on your main point of contact to be that person, and reinforce how it will increase productivity and streamline communication if that pattern holds firm.

Be prepared for roadblocks.

Things will come up — that’s the nature of software development. Your first instinct should be to take all issues voiced by your team seriously, no matter how small it seems at the time. You never know what could spiral. Then, immediately start thinking about contingency plans. Do you have to bring in another developer to pair on that feature? Do you need to cut some functionality elsewhere? Do you need to ask for a timeline extension? Above all, always be proactive.

Unrelated but related: As the PM, you should also be the person your team can rely on to handle these issues as they relate to timeline and budget. It’s no fun saying you can’t meet a deadline, but it happens. Take it, figure out how to fix it, and move on. Your team’s jobs are to code and design — unblock them so they can focus on that.

Set up a rolling QA and continuous integration process as early as possible.

Apps can be big and complicated. Continuous integration helps limit unnecessary back-and-forth amongst your team.

The solution is to set this up early on. I’m not an expert and can’t speak to that in detail (one of the developers on this project is though, so maybe @ him), but it’s a process thing that will save time, so it’s worth mentioning.

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, the language we prefer and use for Android development, is like Javascript, Swift, and Typescript, but it’s not exactly the same. Know that it’s different, and that 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. The 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 UX/design constraints that have to be considered for successful development.

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 Android 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 takeaway is simple: building native apps is harder… and more fun. “They’re a different animal,” as one of my colleagues said. But 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 ;).

Originally published at www.viget.com.