There's Always a Challenge when Developing Mobile Apps

As a project manager, it’s a balancing act to support constant change on a project while also setting realistic expectations. Here’s what I will often hear when I attempt to moderate a discussion in the face of changes:

"Rachel, this is really simple to build. Anyway, we're still figuring things out and the client knows, since we're agile, this could all change."

I feel like I've heard a variation of that line dozens of times. To some extent, the other person telling me to not worry is right. One of the beauties of embracing an agile work culture and app development philosophy is that it allows a team to embrace change as a constant. By definition, you can be active rather than reactive. This can be hugely freeing since it creates flexibility for a team, along with the client, to re-prioritize and evolves an idea/feature set/you-name-it based on new information. And a plus for me: no more change requests 🙏 🙏

But sometimes I wonder if, in our embrace of the agile philosophy (and #hashtag), certain blinders can emerge around project risk — a blind spot for the "worst-case scenario.”

I'm really excited about at a Risk Matrix algorithm we recently rolled out at Fueled to better assess project risk prior to kicking off development. The truth is that during project planning we are always operating off of assumptions and expectations; some are right, some are not so right. And while we thoughtfully plan our projects for a successful wrap, it is also imperative that we think through the multiple scenarios that could unfold at a moment’s notice. “What will happen if the client’s back-end resources fail to deliver the API web service per the agreed-upon spec by X date?” “What is plan B if we find out that the manufacturer can’t get us the latest hardware sample by X week?” It is not that we’re pessimistically gunning for the “worst case,” but reframing our options. Because we always have options.  

So how do we preemptively figure out what our plan B, or C, or even D, might be? Having seen the same scenarios play out over many projects, we are somewhat able to anticipate what an alternate path to success might be.

Here are the five biggest challenges to the success of a mobile app during development, and some reliable solutions.

1. A First-Time Tech Entrepreneur

Being new and fresh to something can be great. You come at a problem with a different perspective and an open mind. The risk? You also come to a project with high expectations and strong opinions that may not be tested outside of your circle or network. If you have thought exclusively about an idea for three months straight, it can be difficult to accept that your concept needs to evolve to fit users’ needs.

The solution: Keeping an open mind and letting stakeholders help you adapt to changes in strategy. The agility of multiple collaborators is the reason you chose an agency like Fueled, but you need to let each party do their thing.

2. Third-Party API Dependencies

Time and time again, I see integration dependencies come up on projects without clients doing due diligence to ensure their web services are standardized and “integration-friendly.” This means there is little to no documentation, best practices are not reflected, or API standards are in flux. What can happen here? Last-minute changes to backend services create a ripple effect on the front-end and we’ll have to spend more time working to address these changes. This takes time away from focusing on feature development and UI polishing.

The solution: Plan for a significant buffer between hand-off of API services and front-end development of those API-dependent features. Creating this buffer will give your development team time to research, test and work with your backend team on any changes that may arise prior to relying on those services.

3. Hardware/Firmware Dependencies

As much as possible, lock down your firmware and hardware specs before agreeing to a prototype or production sample delivery date. Ever-changing firmware requirements will divert our team’s efforts as we then need to continually update the app to support these changes. (The 12+ hour difference with your factory in Asia will not alleviate matters!)

The solution: We realize that firmware development may require iterating to lock in final capabilities and troubleshoot bugs, so plan for that revisioning and an open communication channel between your factory and agency. Most importantly, ensure you have a fluent, on-site product manager/project manager on the ground at your factory that can support this back and forth. Don’t rely on your dev team to project manage for you!

4. No Single Product Owner on the Client Side

Having a client partner that can synthesize feedback from disparate teams/stakeholders, prioritize features and help our team maintain its focus is hugely helpful. There is nothing more heartbreaking as an account manager than seeing a product’s vision compromised over and over because multiple stakeholders can’t agree on priorities or engage in decision-making by consensus.

The solution: Appoint a single, devoted point of contact on your team to prioritize feedback and requirements from the greater team.

5. Development or Design Plan Doesn’t Include User Testing

Not testing an idea, mockup or prototype is the surest way to miss the mark on developing what your users actually need. Often, entrepreneurs shy away from releasing or sharing a WIP product because they are concerned about idea theft (“I need an NDA before I show this to anyone”). Sometimes they believe they already know what their users want (“we already wrote down the requirements from our department stakeholders”). They might, but it’s always safer to find that out before a public launch — especially if they are updating an existing product with a sizable user base. At Fueled, we can be guilty of this “value blindness” as well. In fact, we now require that all projects go through a beta testing period prior to a public release to the App Store and/or Google Play. It gives you an edge!

The solution: Plan for user testing and usability testing during all main project phases (design and development). You'll also need a soft launch/beta release to a larger group of testers once you have an MVP. Any flaws picked up during testing will meet a much more forgiving audience than the general public. Likewise, the stringent algorithms of Google Play and the App Store will penalize poor-performing apps heavily.

Preparing for App Development Roadblocks Will Set You Up for Success

Agile project management allows you to respond to complications that arise during the app development process. Still, the mindset is typically to moor yourself to the okay scenario, design for the best-case scenario, and release with a "this is going to be great!" scenario in mind. This energy can be very motivating for the team and client, as it lays out a strong vision and roadmap of what is possible.

But being aware of the drivers of failure can act as a preventative. By the time you get your MVP to market, you will ideally have shaken out the worst scenarios as hypotheticals. Thorough preparedness will mean your product is refined, robust, and ready to delight.✨

Ready to build?