This article is a transcript from the webinar we hosted on November 6th 2020 on youtube.
This is an informative article about how you can build a successful application. We’ll explore the three pillars of our approach to products. We will also discover why developing a successful application is hard. Then we’ll cover the overview of a product process, which is the application building blocks base. So you will learn the basic steps you need when developing an application and all the basic elements you need.
Note: If you find this interesting and you want to learn more about this subject, you can watch the recording of our webinar by clicking here.
Let’s go ahead and first discover the three pillars to create an application.
We approached a whole building of an application from a creative standpoint. There are two approaches to the way we brainstorm when we go in with a client or for our projects. First, if it’s an already existing product, we look into the past and present of the product itself and improve it. But if it’s a new project, we will look into the competitors, making sure we understand what’s out there and what can be improved from what the competitors are doing. Then we look outside the industry and the products.
We look to find wild ideas, what has and what hasn’t been done in the field or for those particular products and features and try to implement this into our ideas.
We research and analyze what we’ve come up with. We do a roundup of the features. Are they making sense considering the market? We analyze them. We go into a very analytical approach to figure out the things we brainstorm and the ideas we came up together.
-Are they feasible or are they realizable things from a team perspective? —Do we have the resources to bring it to the market? -Do you have internally in your team the resources to bring your project to bear? -Can you hire external resources and have the budget for it?
Here at Algofields we have a point system to analyze each and every feature.
And finally, when you have all these assumptions, you want to test them. You need to test the prototype to make sure the features which you intend on developing, are going to be feasible and something which the clients or the users will like.
-Is it easy to use? –Is it something your customers are going to use and not have to be taught how to use them?
It’s extremely important to test your prototype with current and new customers. Learn more about testing here
Well, the first thing is that the market is unpredictable, very unpredictable, especially nowadays with covid and the pandemic. You can’t really know if your product will be accepted and used and it’s going to be making tons of money. You just don’t know.
In fact, changes based on your current competitive offering will impact it. If you start developing your application and there’s like five or six competitors in your field and your industry, while they’re going to develop their own features, too. And if they hear about some of the features you’re doing are pretty cool, they might replicate the same thing unless you have a patent on them.
For this reason, you want to make sure you understand what they’re doing, where they’re going and adapt to it. Because if you do all these new cool features and your competitors are copying and they already have an established client base, you’re going to be in trouble. There’s also the changes in the microeconomics which have an impact on your offering. The covid right now is a great example of this.
The second thing you want to cover is the features you build for first to get traction in your MVP. This is one of the areas which requires a lot of research and understanding what the market demands. If you decide to build these features like five or six features in your MVP, what are they going to be? Because you don’t have tons of developers like an established product, you want to focus on the right features.
In most cases, it may take some time before you get to positive revenues, especially while you invest on getting traction and if you take the freemium approach. So, if you understand your burn rate, you get an idea of when you’re going to run out of cash.
I’m not selling these points to discourage you, but to give you a brutal truth about the prospect of building your applications, you need to understand these things.
Let’s explore these elements to minimize the negative effects of what we just discussed. What I would recommend is to make sure your application covers these main elements before you release it or do better testing. Because if you don’t cover these already, you’re setting yourself for a hard truth and the hard of release cycle.
The first thing is stickiness. How do you make your application sticky with your user base? Think of Facebook or Snapchat or any social networks, whenever something new is happening, our friend is posting something on Facebook, you get a notification. This is a form of the statement and is crucial in making your application sticky.
If you think of any applications you’re using repeatedly, there’s some form of engagement, of stickiness which brings you back to the application.
We need to talk about values. In fact, without values, engagement and stickiness doesn’t bring much. For example, Facebook, Snapchat, there’s a video, there’s value brought to you. When you engage with these applications, you want to make sure you bring a lot of value. If you think about these dozens of applications in your field and industry, what value do you bring on top of your competitors? And is it enough to justify a move?
Users typically have an aversion to change. If somebody says tomorrow I’m going to bring a much better Facebook, then Facebook, would you move to the second version or second iteration of Facebook? I doubt it. So, To make people move from Facebook to another application, you need to bring value and stickiness. Think about yourself again:
-What would it take to make you move from the current applications you’re using? -Who are the competitors? -What are the major competitors and their user base? -What would make them move from the old application to yours?
This is the user experience part of the application. This is something we’ve covered a lot in here.So how does the UI, our graphic interface, enhance the user experience? There are several prototype elements which can hinder the user experience and you want to make sure you’ve covered all the major points such as the overall theme, the ease of use and the two clicks rules. Learn more about these elements here.
Don’t go into development of your application without testing the UX. Once you get to a prototype, you test and you ask this question; when the users play with your application in testing, with your prototype, do they need explanation for each function or not? If they need to be explained how to use your application, it’s already a bad sign.
Last but not least is product GTM. If you’re not familiar with this acronym, it’s your go-to-market plan. It’s how you’ll reach your users with an overall value price, overall competitive value and pricing which will make them switch to your application.
This is how you explain your value to users, which should be hand in hand with your messaging. You can have the best value and a very sticky application but you’re not going to reach your users if you don’t have a good go-to-market plan.
The next thing I want to cover is the process of building applications, so where does this start from? if you really are at the beginning stages of all this and then where does it go from there?
The first step is to identify: What is your “why” for your product, your startup? Look at your portfolio, look at the features which you’re not sure if it’s providing the right value to your customers or not.
At the beginning, you want to start with what’s the motivation for changing your portfolio, your product, or creating a brand new startup? What is your motivation? Because this is what is going to keep you going when things get tough and it takes a lot of internal motivation. This is really something you need to nail from the get-go.
What you need to do in this ideation part is to take a look at what are the best ideas you came up with. Then start brainstorming those, then start drawing what it looks like.
I think it’s a good creative process which a lot of people like because it’s free, it’s a free process, for starters. And you can iterate your ideas over and over again until you get to something solid.
This is when you evaluate your ideas. You make sure your ideas are feasible. The competitive land isn’t too full of these types of features and products. This is the area where you need to stop yourself and cover the logical aspect of the ideas you came up with.
Now you bring your ideas into a digital realm where people can test it and then you go back to the prototype and test it again. We’ve covered this in one of our webinars. Watch here for more details on the subject or read this.
This is what we’ll cover and more details later, how you go about doing product development so you can bring an application which has the element we’ve covered previously, successfully to the market.
Finally, the go-to-market phase. This is what we have covered earlier. We discussed the competitive landscape distribution, distribution channel, your business model, your launch plan, your pricing, etc.
Now, what I’d like to cover is the actual process of developing an application.
Let’s say your company already has an internal team, what you could do first is determining what you have internally in terms of skill sets to bring this application or to develop this application successfully?
But if you don’t have a huge team or your own internal team, you need to find a developer. You need to spend a lot of time making sure you select the right developers. Therefore, don’t rush this step because you’re going to hate yourself down the road. If you don’t select the right developer, it’s going to cost you and take much longer to develop the application. For example, you’re building a mobile application. You need to ask these questions:
-What A.I. features does the developer know? -iOS and Android development inside out? -Do they have Java, Swift and Python programming languages, expertise and modeling experience for A.I.purposes?
Once the developer is selected, you need to make sure whether they provide a detailed plan to execute all the features with estimated time frames.
If they don’t have an actual estimated time frame and specific point system and elements, then run away from these guys, because you’re going to hurt yourself and it’s going to cost you down the road. And if they don’t and they’d rather you have one, build one yourself. Maybe you need to become a product manager and somebody with a PMI certificate and have the proper skill set to build a detailed plan yourself and discuss it with them.
For example, internally here, we use Asana and this is where we build a board with a point system which we review weekly with our developers, what is called a stand-up meeting. What we want to make sure every week, is understanding the velocity of the team as the project progresses. (If you’re not familiar with this term velocity, it’s how many points a team can deliver in the weeks’ time.)
Whatever is the velocity your team can deliver over time, and you can execute and have a deadline which is at least very precise or very close to being precise.
The testing is something I’ve said many times in our previous webinar.
It’s imperative to understand what has been developed is acting like intended. When you do this at the prototype level, you test with external users, your potential customers. Will this application be something they like? Is it user-friendly? Etc.
If you’re interested in developing your knowledge about the testing steps read this.
As you develop the application, you need to test it first internally before you shoot it out to the world. Every week when somebody completes a task they need to send this to another developer for testing it.
Are features doing what we intended? If not, you go back to development. If yes, then it’s ready to be tested out to the users outside.
Once the feature is tested and approved to deploy to the application, you need to move from the internal server to a staging server with users.
A staging server isn’t a server where you have your production, where all your users are on. This is where you have maybe one percent, five percent or 10 percent of users. They’re going to give you feedback on the new feature. And if there’s any bugs or any unintended problems with the new code, it will show.
So you need to make sure you’re doing this internal testing with a developer, to the staging with users, and then you move on to live production.
In order to release a successful application to the market, you need to spend more time detailing and researching these building blocks:
First, the dev selection, you want to make sure you select the right guys, the right team. Then you want to make sure you have a proper plan and executed with very specific numbers and metrics which you can track every week with tools like Asana and Jira and any project management tools out there. Finally, the testing phase, making sure every time, somebody else than the developer, is testing it and giving feedback on that developer. Somebody else is more objective than yourself when you’re developing something and releasing it to the world.
All these steps are there to ensure a smooth development path and prevent avoidable issues through development cycles and testing.