Being able to communicate your ideas lucidly and in a systematic manner is one of your biggest qualities as a leader. Throughout human history, the ability to communicate new ideas have ushered not just changes, but revolutions.
But, for the sake of this blog post, we are going to put aside the thoughts of triggering revolutions.
We are going to focus on how to explain your app idea to your app development team effectively so that the team can build your dream app just the way you want it.
Why is it important for you to be able to explain your app idea to your development team effectively?
Not being able to explain your app idea to your development team causes unnecessary delays. For example, not understanding what you actually want, the development team invests time and energy on building something you neither want nor it is useful for your business. The entire effort goes to waste. You and your development team may need to start everything from scratch.
What happens if you are unable to communicate clearly to your developers?
The biggest casualty of course, as mentioned above, is your idea itself.
If you want to solve problems, if you want to change the world, even if you want to change the life of a single person, the idea remains unrealized due to a simple reason that you are unable to communicate the app idea properly.
You may go through
- Loss of new business opportunities because the app didn’t reach its potential.
- Loss of money as the money you spent on development and acquiring technologies didn’t bear the fruit.
- Loss of time that you could have spent on other productive activities.
- Further loss of money and time when you start from scratch and other try the same team or hire a new one.
Remember that it is one thing to be a visionary, but totally a different thing to actually capture the vision and convert it into a three-dimensional product or a digital product.
Take for example Steve Jobs; one of his biggest strengths was that he was able to clearly communicate his vision and design philosophy to his product designers. The product designers then could do the same with the manufacturers.
Hence, when you are explaining and communicating your app idea to the team that is going to work on it, don’t just assume that they understand every aspect of your app idea.
They may have a different vision. They may have had different exposures.
They cannot see what you can see.
Listed below are some ways you can clearly explain the idea of your app to your developers.
Introduce your company
Well, there’s no need to introduce your company if you have an in-house team of developers. But if you are hiring or contracting the team merely for developing your app, it’s better you provide some details about your company.
Once they know about your company it’ll be easier for them to understand your goals and the nature and scale of your target audience.
User stories can help you explain the concept of the app using real-world scenarios
Our brains are tuned to pay attention to stories because we can empathize with the characters.
When we empathize with users/customers, it becomes easier for us to understand the problems being faced by them.
When we use user stories, we don’t talk in terms of features, but in terms of end goals – from the perspective of software users rather than developers.
These are very small, specific, model-based stories. They talk about a person who has a certain problem and he needs to solve that problem. They don’t have to be elaborate. Even a single sentence would suffice.
A typical user story template would be like
As a < user > I want < some ability > so that < something can be achieved >.
As a student, I want my app to allow me to quickly create notes, that I can later retrieve in their logical sequence.
As a music lover, I want playlists to be generated by my favorite bands automatically.
Explain to them how people will be using the mobile app
Take, for example, you want to develop a mobile app for people who quickly want to browse through news of the day without going into much detail – maybe 40-50 words at the most.
You should be able to communicate to your development team that the app will be for people who are in a hurry, who don’t have much time but they don’t want to remain less informed of their fields of choice, whether it is politics, sports, current affairs or glamour.
In a single glance, maybe in a highlighted horizontal rectangle, they should get the complete list of the news item and then move on to the next news item.
They might use the app during the 5 minutes extra they get while standing in some line, or while using public transport, or waiting for the lift. This means they should be able to access their newsfeed as quickly as possible and without distractions and without extra information.
Your typical users may not even want images and videos.
If you don’t tell this to your developers, they may include images and videos, considerably increasing the load time of the app, or creating extra modules for handling images and videos.
While they add images and videos, they may also include social networking features to share those images and videos whereas, you don’t want that feature in your app.
But if they are aware of the circumstances under which your typical users will be using your app, they will be more empathetic towards their needs and, build the app accordingly.
Aim for a minimum viable product (MVP) in the beginning
Why have all the functions at the beginning itself? Although you may have time-to-market constraints, you will be surprised to learn how fast and efficiently an app can be developed if it is built in stages.
You want your app to be able to do every possible thing you can think of, right? Understandable. You want to create a Swiss Army knife of an app. Understandable. You should definitely if you have the resources and the plan.
But, you will be able to communicate your idea more effectively to the development team if you take the development process in stages, knife by knife, screw by screw.
Focus on the strongest and the most-desired feature of the app and ask your development team to work on that. Then release the basic version.
Going back to the above example of creating a newsfeed app.
What about accessibility features? Should the users be able to use their own fonts? Should they be able to increase or decrease the size of the fonts, or the news alerts themselves (maybe 100 words instead of 50 words)?
It would be better if the users of your app can share important news with their contacts, maybe through WhatsApp or Twitter. This is an important feature, but you don’t need to incorporate it in the first release itself. You can just focus on creating a very light newsfeed people can quickly browse.
A great benefit of releasing the bare-minimum version of your app is that you can get healthy feedback from people before you invest more time and money and not only make further changes but also add more features.
Divide the app into smaller modules
No matter how prodigal your development team is, if you bombard it with too many feature requests, the team members may get overwhelmed and end up heading towards a wrong direction.
Of course, inform them that the current module that you are discussing isn’t the entire app, but a small portion of the app and they should keep provisions to add and connect different modules and make it possible for them to exchange processed data with each other.
Communicate your idea in smaller chunks.
Take help of flowcharts
Flowcharts these days are very easy to make. You can even use PowerPoint to make flowcharts or if you don’t want to use PowerPoint, you can also have a simple whiteboard and draw the flowchart upon it.
In programming-speak creating elaborate flowcharts is also called “wireframing” and it isn’t necessary that only programmers and developers create wireframes.
Just as your development team can create a wireframe to explain to you how they’re going to proceed with the overall development of the app, you can also create a wireframe to explain what you have in mind.
You can also create a mockup or ask someone in your office to create a mockup if you want to be more elaborate. You can even ask someone from the development team to help you create a mockup through which you can get the entire process drawn along with various elements of the interface.
A flowchart can be as simple and as complex as you want. A great thing about a flowchart is you can visually explain where the journey starts, what turns and twists it takes according to various if-then-this-else-that situations and ultimately what it leads to.
Think your app idea is too complex for a flowchart?
A flowchart is not a single entity. As discussed above, you can divide your mobile app idea into smaller modules.
In the same vein, you can divide your flowchart into smaller flowcharts focusing on specific modules.
Develop a communication process or protocol
How often should your team give you updates?
How fast should the team respond in case you have a concern?
How can communication be more effective and faster – email, Skype, Google Hangouts, Microsoft Teams or Slack, or another communication tool?
Once you have decided upon the communication process or protocol, the entire team will stick to it and you will be easily able to communicate and give feedback.
Explain the deadline and the budget for your app idea to the team
Having a feasible deadline will allow you to get your app completed on time. Similarly, having a budget will give your development team an idea of how much effort they need to put in to give you what you want.
Suppose you want an e-commerce app to enable your customers to buy Christmas gifts.
It is June and one week before Christmas, you want to reach your target downloads so that by the time the festival comes knocking, people should already know that they can use your app to buy gifts in a more convenient manner than they can do on other websites and through other apps.
So, you not just need the app completed by September, you also want marketing and promotion of your app to begin by the third week of September.
This, you will need to clearly communicate to the development team.
While deciding on the deadline and the budget, you should also trust the development team as they may have a different take on these two aspects of your app project.
Remember that finally, they will be the ones working on the project, and having worked on many more such projects, they have a basic idea of how much time such projects take.
Being able to communicate your idea can be a matter of survival sometimes.
There is a documentary that shows a couple living in the jungle the way the primitive people used to live, with the same Stone Age tools.
Hunting was a big part of survival.
Whether they got sufficient nourishment depended on whether they were able to hunt or not.
Communication is the key for the couple as, just like primitive man and woman, they cannot use language, but still, they need to plan how they are going to carry out the hunt for the next meal.
Through their communication skills, they need to plan how they are going to protect themselves at night without becoming a meal themselves.
Communicating and explaining your mobile app idea to your development team may not be equated with hunting to survive, more or less, the concept is the same.
Your ability to communicate and explain can make or break your great business idea.
The key to carrying out a better explanation is, taking the need to explain seriously.
Seriously, many projects fail because there is a communication gap between the person who comes up with the idea and the development team that tries to transform that idea into a business app.
Have a communication plan.
Write down the steps your team needs to follow.
Make a list of the most important features without which the app has no meaning and then decide to focus on those features instead of other, additional features that your app may have later.
Half the work is done once you have explained your app idea properly.
Dhananjay (DJ) Goel is the CTO at Alphalogic, passionate about technology, startups, game of thrones and coffee. He enjoys working on challenging problems with innovative startups.