The Continuing Process of Gathering & Analyzing Users Requirements

Gathering User Requirements involves a process that uses several different methods and sources to find and collect data. This can be comprised of information from interviews, questionnaires , A/B testing and focus groups that will then, in turn, be analyzed along with your Key Performance Indicators (KPI’s).

A common mistake people make is that they tend to treat themselves as one of the users. Like a horses with blinders, we often myopically base what we think the requirements list is, solely on one’s own selfish needs and not on the real and objective needs of the users. The correct way is to first adhere to the process of gathering User Requirements before deciding on what you think those requirements ought to be.


The gathering of user requirements is in fact more a process than a methodology. Sometimes having the right attitude towards collecting data gives you interesting results.

Gathering requirements involves a process that has several phases: First, gather data before launching the product, then gather again while launching the initial release of your product, and when the last phase occurs, keep collecting data while continuously building improvements into the product as it develops from one version to the next.

The Method for Gathering Requirements Before Building Your Product

Defining your method for gathering Requirements is the most important and hardest part in the process of product development. Before you are able to define and understand who your target audiences are (and there may be of course several different sub groups within each audience) , you first need to have a strategy of how to approach them in the best way.

The decision about which methodology strategy you use happens at an early stage, where the product is, as of yet, still not developed, so you will here have several opportunities to test your idea and show to users an initial mockup or sketch of the user interface.

While explaining your product and idea to users, emphasize to them the needs it addresses and the functionality it will have. Here, I would like to suggest that you use some sort of a visualization tool so that while you gather data, you can be assured that you are on the same page as your users, which is helpful in understanding the what for them the product really is and what it potentially can do.

When speaking with each user you approach, take note of how they envision this as a solution to their needs and try to understand what they would expect the product to have and do for them. This will ensure that what you include in your requirements list contains what is most important for them, and what they think needs to be included in such  offering.

If your users are part of any Registered Professional organization, then finding ways to reach them will be easy, sometimes you can get a hold of a list of all members and approach them individually by phone or en masse by email. Sometimes creating a crawler or data email signup list can help to gather user emails; these days this is the method that is needed and sometimes it may come from posting several articles in online discussion groups as a way to try to collect peoples’ feedback.

Once you have made several passes in the process, you may have by now managed to come up with a list of users’ requirements that you know should be in your list of requirements. Sort this list by importance, with the most important requirements that should be included in the Minimal Viable Product.

The process of sorting the requirements analyzing them and then taking only the most important ones will help you get to the next stage, deciding on what are the key elements of working.  In this process you will always have a long list of requirements to choose from, at every step you will be making judgments about including only a few of them, because the ones that are the most important and also more relevant to the direction of the product you want to take should be implemented first.

Collecting user requirements by using data collection methods that will allow you to analyze and run tests on your Minimal Viable Product (Minimum Viable Product).

Here are some examples of Gathering techniques that I have recently seen –

  • Using Facebook groups to place an incentive or hook that will attract users to respond to your offering or you can cultivate interest by building your own group on Facebook of users that share a common interest in regard to your product’s need requirements.
  • Approaching users, one-by-one, using Facebook as a tool to connect to an existing Facebook group that others belong to. Of course there are many other sites to do this with, such as Quora or Linkedin, the point is to be inclusive to users that share a mutual interest with you and in some cases this can make for a very good initial user base for gathering, inquiring, and researching needs.

 

Gathering Requirements While Launching the Initial Release of Your Product 

“If you are not embarrassed by your first release, you’ve launched too lateRied Hoffman

Adhering to the lean start-up model as a way to begin to build your Minimal Viable Product (Minimum Viable Product) as means of trying to push your product onto the market with the minimal amount of functionality and features needed. By getting to the market as quickly as you can, you are better able to gather data about users’ requirements by getting feedback from your trial’s users.

Once you are better able to handle their responses and be able to pitch your idea elaborately with users, you have the opportunity in this  initial stage to study a closed group of users. This initial closed study group of users usually referred to as “Alpha-group”, because this data is gathered privately and only they, the users, are given exclusive permission to use and evaluate the product. Keeping this group in a manageable size will enable you to gather quality data about the user’s  requirements and analyze them according to their corresponding scale of which of them is the most important. There are several more possible methods to use, including intravenous and focus group studies, you can also run A/B testing trials and check the data that comes back with what works best for users and what features bring the best conversion rates.

From this place you should be able to now collect and sort through a list of requirements which have been verified by real users that have used your product in some way and are now ready for another round of Alpha testing or for the next release version of the product.

The Process of Continuously Building the Product from One Version to the Next

Working lean means that you will be directly going out to the public to release your product, you therefore should be prepared for the next stage of building your product and what you need to consider when you are about to launch your product, knowing full well that your product’s launch does not represent the perfect version of your product, but it at just another stage of its development. Because the Minimum Viable Product is what needs users feedback, your methods for gathering lists of these requirements should be focused on what most needs to be taken care of first.

the process of developing an idea into an invention requires several passes in a cycle that focuses on things until their problems are solved

Here is where you should define your cycle/sprint length. In other words, you need to define the duration between the timeframes of being able to offer different versions of your product. What is the cycle duration of when they are released, and what is the length of time between you coming up with new versions versus your ability to collect and analyze your user feedback? How much time does it take to gather data about user requirements and then to analyze them in a way that enables you to come up with a better version of your product upon its next release?

Building the product as it moves from one version to the next means that you paying attention to the importance of starting up lean. You are not supposed to add that many features all at once, but your testing should move slowly from one version to the next in quick short cycles that will enable you to understand how users change their perceptions and behavior when new versions are offered, and it is important to be able to collect and analyze the data in real-time.

This discussion also relates to other discussions about the Key Performance Indicator (KPI) in earlier posts. This demonstrates the importance of first defining which are the KPIs that you are going to follow so you can have a good understanding of the experience of product / user engagement

Summary

The method for collecting user requirements is involved in an ongoing process which starts with the initial sketching out of your idea. This process continues in quick cycles as your product development moves from one version of your market offering to the next. There are several tools that you can make use of that will allow you to easily understand what  the users’ requirements are, and in the meantime make you able to analyze & prioritize your list of requirements so that it is sorted according to the most important ones first. This way, as you release new versions of your product, the expectations of the marketplace are easier to fulfill. This process of running in short circles between version releases is an important aspect of guaranteeing the successful evolution of your product.

  Contact JumpStartCTO if you need help with your venture

    Post Navigation