As a consumer, there’s nothing more frustrating than dealing with customer service when you have a question. It’s a never-ending cycle of being transferred from person to person until finally, you reach the last caller who’s able to sort you out within minutes. The problem is you’ve now spent an hour on this journey when the outcome could have been reached much earlier. Frustrating!

As an app development company, we’ve seen and been in similar situations where we’ve ended up taking the scenic route when finding the solution to a challenge. Not only does this cost us time, but it takes us away from being able to concentrate our resources where it matters most - building out meaningful features and interactions in an app.

At Moonward, we’re all about efficiency. We value the journey that clients embark on with us as we progress through a project. A key part of this journey is our ability to be transparent in our communication with clients and lay everything out on the table, both the good and the (rare) not-so-good. 

As a team that is 100% in-house, there’s no reason for us to not be including our developers in the conversation with clients. In the past, we noticed a disconnect between the work that was being put out versus the vision that we were working towards. The product team may have been 100% on board with the ultimate goal and vision, but we found that the developers themselves weren’t quite on the same level or depth of understanding.

If the team building your app doesn't share the same drive and ambitions, how can we expect to deliver a product that will go above and beyond and to the moon?

It all begins with communication. It’s easy to fall into a loop of miscommunication and misinformation when nobody is singing the same tune. The last thing we want is to build a wall between the developers, the designers and the product team. So how do we get past this?

The answer is simple - get developers more involved. Start by building that face-to-face connection, bringing them into meetings and communicating directly with the people who need to hear it. It might seem trivial, but the way one person might take in information or perceive feedback could be completely different from another person. We don’t want to be playing Chinese Whispers with information being passed from team member to team member.

As a product owner, we’re more focused on the bigger picture and getting to the end goal, as opposed to developers who hone in on the intricacies of how to implement a specific feature and the cascading effects it could have on the overall architecture. There’s nothing wrong with either viewpoint nor is there a definite ‘right’ way to approach consuming feedback. From our experience, the best discussions we have are the ones where all stakeholders are involved - and that includes our devs. To leave one of our key players out of the conversation would be like venturing to a new place without using maps. You might get there eventually but the trip won’t be without bumps - it’s much easier to just use maps the first time, trust me. 

It’s also important to understand that in app development, a feature you might think is merely a simple task could be a feature where the dev complexities far outweigh the value it brings to the app. That’s where developers come in with their expertise to guide you in making informed decisions about where we should be pointing our focus to. We love questions, and we love oversharing our knowledge about clean code. 

So the next time you catch one of the devs in a meeting, don’t be afraid to ask questions. Because I’m sure they’ll have some for you too.