Site icon Youth Ki Awaaz

4 ways to prepare before reaching out to developer !!

Before-going-to-developer-

The time before starting your own company or launching your product is the most exciting time. Here you spend hours doing research, you keep reading about the competitors, have a lot of new ideas, there is motivational content all around you, and you feel all ready to start building your website or mobile application. You want to get your idea developed, become the next Steve Jobs and build a brand like Apple. And you very well shall become that if you plan it properly and avoid the cliche mistakes.

One such mistake is made by the founders while they are getting their application made. It is being unprepared and keeping the scope of assumption on what you want to get build. What may be an assumption for you may not be such an obvious assumption for your technical partner. Hence things can get nasty. At Graffersid, we spend initial 14 days only researching and documenting the client’s market’s tech domain and finalizing the features.

Don’t wear sneakers for a morning walk; Difference between Development Preparation and Business Preparations 

<p>Your market research, competitor analysis, business model planning and your launch planning are the preparation on how you would run your startup. But your product preparations are different, the same amount of effort goes into finalizing how your needs to be built. Although, it is your tech partners role to guide you, however, companies in today’s highly competitive market may not dedicate so much time. Therefore, it is better to spend some extra days making a written document of everything that you desire. </p>

<p>And NO, I don’t mean you become a geek or a coder, all you need to do is make a detailed document on how things will work on your website or mobile application, a couple of documents mentioning the list of features with the URLs, and a list of competitors. Now let’s discuss this in detail to understand how it can be useful and what things should you take care of while creating it. Below I will also explain how is your competitor analysis different than your Technical Competitor analysis. </p>

When you prepare for a WAR, it is better to know your enemy 

This list will be the foundation of your preparation and will act as the backbone for your other documents. Let’s say you are making a grocery application for Indian Market, try to find out other competitors in this domain. In this case, the Competitors could include Groffers, BigBasket, Nature’s Basket, all these are your Indian competitors in the e-commerce segment. While creating a market competitor analysis you might also include, Kirana Stores, Walmart, etc. which are your offline competitors, however, they may not be required for the Technical Competitor analysis.

Break your competitors in 3 to 4 segments: 

This particular document will come in handy for gathering new ideas in which mobile app could be used to generate additional business and attract more customers. If technology is used properly it could save you 30% of the marketing cost. Let’s see what all information can get out of a list of competitors that we have just created.

Finalizing feature is like a girl in a mall trying buy 1 dress (Sounds easy ?) : 

Features are the most important part of the application, it could be the deciding factor on how users would use your product. Even if you make the most beautiful product in the world but the user does not have the required functionality to reach to his end result, it is very likely that he won’t use your product twice. Moreover, it is better to discover all the required features before-hand because adding a new feature in development phase or after the product is built could take significant efforts and delay the release of your product.

 Make a list of all the features: 

The most common features are the most likely ones to be missed out. It could prove to be disastrous in the later stages of the development. Hence, list down everything you see in any of the competitor’s application. Things even as small as login button, cart option on the left top corner, etc. There are 2 reasons for doing such a tedious work. </p>

  1. Discovery and Finalisation of Features:
    When you have a detailed list of all the features that currently exist in the particular domain, it becomes easier to discover new features which could help your end users. You can find interesting combinations of features which could dramatically improve the UX.
  2. Ease of explaining:
    When you share this document with your IT partner, it would be easier for them to understand your idea in depth. Moreover, it would also reduce the chances of confusion and assumptions.  This would help you in reducing the time for getting the work started. And, ensuring that the development goes smoothly without any surprises.

Your product is like your life and your documents are like the gym:

If you don’t go to the gym you won’t die, at least not immediately, but if you do go to the gym you surely live more healthy and longer. Once your list of features is ready, you can now start to analyze which are the absolutely necessary and which features are just and overheads. As a new product in the market, you don’t want to be too bulky or tough to understand. So try to keep the UI very simple and self-explanatory. Have only those features which are necessary and highlight your USP maximum.

 Create a flow diagram for all types of users, as the last step, create a separate excel sheet document with all the types of user roles written on top and all the final features on the left. While noting the feature make sure you write them down in the flow they occur. Like,

  1. Signup
  2. Login
  3. OTP
  4. Profile
  5. Product Discovery
  6. Categories
  7. Search, etc.

The reason to write it in a flow is so that you don’t miss any point and the reader of the document can understand your mindset towards the application.

 

Beneath each user role writes in detail about the information required and the next possible actions he could take from his current stance. Mention it in as detail as possible, to a level that you never have to use “ETC.” in the complete document. Moreover, try to also depict how an action of one user role affects the other user roles. For ex: if the delivery boy is out for delivery then all the other users will receive a notification about the same.

 Conclusion 

Do this and you would reduce the chances of entering into dispute by 80%. For all future reference, you can refer to this document as the agreed deliverables. It does take some time and lot of efforts but then again the startup is your dream it is completely worth every second invested. Wish you all the best, hope you have a great experience and build some beautiful products. Achieve all the success you deserve.

 

Credits: Graffersid.com

Exit mobile version