From Idea to Reality: A Requirements Gathering for a Startup project

Usually when you start a startup project, either as investor, developer or company, you need to gather some information. Based on this information, development team will be able to make some decisions, for example, they will decide on: programming language, hosting platform, team members and tools. In this article, I will show you which questions I typically ask my clients, and how do I work with them in the discovery phase.

The Tool

You might think that it is not that easy to properly get useful information while freelancing remotely. That is not true, you just need to use proper tools. While working with many international clients, I usually used Miro app. It is a great tool for creating diagrams, mind-maps and other graphical representations of your ideas. In most cases, it will be enough for you to have any diagramming tool. However, it is useful to have collaboration options like Miro has. Collaboration makes it easier for the client to add their ideas as well.

I am describing requirement gathering for startup project based on my app LearnReader. Just to make it more clear for you, it is an app that allows you to easily collect words for language learning. For example when you are reading foreign news website, you can select phrase and collect it.

The Persona

The ultimate classic of all workshops for requirements gathering is Persona. Persona is a typical user which will use the app. Of course, you can’t predict that 100% accurately, but the client usually has some idea who is the main target of the app. Here you might add some picture of the example person from the internet. Predicted age, gender, occupation etc. Generally, I put here all the information about the target persona I can think of. All this information will be useful for a UI/UX designer.

Persona planing

The Problem, The Background, and The Preferences

The most important thing I usually want to learn, is the problem. What problem the startup project is actually solving? In that case, the answer would be “Too problematic process of collecting your own vocabulary for language learning”. Thanks to this information, I can learn what the app wants to achieve. I can propose some alternative solutions, which might suit the client better. It is also useful to learn what are the similar apps that client has in mind.

Another key information are clients’ preferences for their startup project. As programming is my job, the strategy is the clients’ job, I need to adjust my work to it. Here are some important questions I usually ask about.

  • What do you care about? – It tells you what do you need to put the main focus on – Example answer – “Quick release of Minimum Viable Product”
  • What is good to have in the project? – Putting a focus on this will make your client happy about your progress – Example answer – “The least possible amount of bugs”
  • What is the least important? – It tells you what can be left for later, it shouldn’t be your priority – Example answer – “Performance”

It is also useful to add some question like “Additional preferences” If client wanted to add something additional.

Other than that, there are several questions that might define some technical aspects, like hosting services. To learn more about technical requirements it is good to ask about SLA, minimal market share supported, destination market and predicted user base.

Below is an image from my Miro Board template.

General Requirements Questions for startup project
General Requirements Questions

Feature requirements for Startup project

Gathering a substantial amount of feature information is a huge challenge. That is why all of this actually happens in Miro, and it is not a normal voice call. At the beginning, I ask about all the features the client has in mind for this application. I am noting them as empty frames in Miro. Each frame is named with a simple feature description like “Easy phrase adding” or “Collection View”.

Basic feature list for startup project requirements gathering
Listed features

At the beginning of freelancing career it was my huge mistake to not deep dive into feature details. It resulted in constant need for communication and asking about details. Of course, you will never get rid of communication, during development. But you can make it less frequent.

Let’s make an example from “Collection View”. It sounds very general and does not really tell you anything. You only know that it will display Collection on this screen, but are there other features? Thats why I ask about other things that client would like to have there. In that case I would ask questions such as:

  • Can you add a phrase manually?
  • Is user allowed to edit phrases and translations?
  • Can you delete them?

Based on the answers, I have already added 3 more frames: “Collection View—Add phrase”, “Collection View—Edit Phrase” and “Collection View—Delete Phrase”.

Startup project requirements - gathering feature requirements in details
Divide and Conquer – make the features smaller

Jump into the details

Now, when I have divided general features into smaller ones we can dive even deeper. It is time to define what should happen in specific situations.

Discussion on a feature flow I always start with the question “How does it begin” – What user does to enter this feature. Based on “Edit Phrase” feature flow, I can learn that each phrase can trigger a menu with options for the selected phrase.

Edit phrase feature flow
Edit phrase feature flow

While making this flow I think about all the edge cases that might happen, what are the possibilities that we give to user. Then each case has its own behaviour – it is a good place to discuss with client such things. It will narrow the need for a contact during development of a startup project.

And that is how I go through all the features and sub-features, to learn as much as possible. Of course, If the client is short on time, we make a decision on deadline of such discussions. You could throw ideas and edge cases forever if you don’t have a deadline. So you should have it anyway.

Summary

That is all for now. I will update this article once I add new steps to my requirement gathering process for a startup project. Other than that, such calls are usually supplied with casual questions about the project and note-taking. Such standardized process helps to gather all required information for the developer and the team. If you have any questions, feel free to contact me on email: jakub.neukirch@stonks.tech or through Contact Form on this page.

Stonks Software House

We make mobile apps. Fast. And also blogging about app development.