Even from the first days of our life, we are curious about the world around us. Within the first couple of years, we begin asking tons of questions like “Why is the grass is green?”, “Why does this man have red hair?” or “What makes a car move?”. These questions stem out of curiosity, and in fact, they are very crucial for us. We have an innate drive to seek out the unknown answers because we need to create an explanation for the world that surrounds us. As time goes by, most people lose this superpower that we call ‘curiosity’ and stop asking questions. Instead, they develop another one – to provide answers that are not clear or concise. This manner helps most people hide the fact that they don’t know something or helps them avoid those larger degrees of responsibility. Both of these powers actually work unconsciously.
Why are people afraid to ask questions?
A few years ago, our client provided me with feedback about one of our software application developers: “He has more than three years of engineering experience; however, he is a junior developer. He knows it and that’s why he’s afraid to ask questions. He thinks that questions can make him appear less knowledgeable. The problem with this particular developer is that he doesn’t know what questions are senseless, and which are not.” Close to the mark! The client was right about the formative assessment of this particular engineer. Years spent in software development doesn’t necessarily make for a high-level developer. After that conversation, I’ve started to pay additional attention to the types of questions our developers were asking, while also taking into account the introvert / extrovert type of their personality. Still, the right inquiry means that the person understands what is going on and needs to confirm or find a solution.
There are a few reasons why some people don’t ask questions:
- they are afraid of looking foolish;
- they don’t understand the importance of the answer;
- they don’t want to interrupt or interfere;
- they feel like they already have the answer, and in their opinion, it suits.
All of the options can be attributed to personal issues, but they can have a significant impact on your business or even ruin it.
Back to business: the overview of software development questions
I have a personal belief that every question asked can save money for our client or me. As a product manager for many projects, my work at Dashdevs is tightly connected with communication and asking questions. My role requires me to know what-why-when something is happening in my web or mobile applications. This requirement extrapolates to the product and digital system in general. I convey the business requirements to the development team and control the software development process.
Usually, I ask many questions to our clients and stakeholders because we are an outsourcing software development company, and we are not sitting with them in one room day-by-day. A client comes to us with their vision of the product and asks us to provide them with a design, architecture solution, and development capacity. Sometimes clients come with their image of the solution for the product. Unfortunately, it is not always the best one, as most business owners have tunnel vision and cannot stay objective. That’s why, when I get another request for web or mobile application development, I start to ask questions to the stakeholders. I don’t want to be misled by my own world’s perception. All issues are important for me because they can change the software product architecture, user interface (UI), and user experience (UX) in the app. All answers help me better understand the business requirements, which lead to developing the best possible digital solution.
Before we start the development process
I love my job because it allows me to work with totally different companies, products, and markets. I can create a cross-market solution and design systems of various complexities. All applications developed by my product teams are beloved and precious to me. Even though Dashdevs is an outsourcing company and fintech consultancy, we are usually working as an augmented product team. It means that we must be on the same level of digital product awareness as the CEO of the company. We need to understand the product from different sides — business, marketing, and functional. Typically, when a new client comes to our company, we set up a kick-off meeting to understand the business and product requirements in a short period of time.
Let’s walk through a few important questions that are usually ignored by product owners at outsourcing software development companies and I will try to explain why answers are so crucial. I’ve grouped the questions into the following categories — business, marketing, and functional. A typical case is that we may need to speak with several people to get the right answers.
- What are the strategic goals of the application for your business? — Some solutions have functional purposes, and some are just image-building. We’ve built hundreds of minimum viable products (MVP) for our clients, and thus we know firsthand that the main goal of an MVP is to pitch the idea to VCs or test the market and proceed with fully-fledged engineering. After the presentation/test period, we rebuild the application or extend it. The answer defines the architectural approach and the requirements for the quality and scalability of the software product.
- Why do you think this application can be in demand with users? — Usually, there are at least a few competitors on the market, so how can a new digital product become a leader? It is necessary to understand the client’s vision since the idea to create can eat away at them and lead to the loss of the product’s primary goal for the business. You may have heard about the Dunning-Kruger effect, which causes personal biases that can ruin a business. On the other hand, the answer can open additional strategic requirements for future development.
- What information or resources about the market do you have? — I need to know the results of market research, have a list of competitors, and gain access to their applications. I need to be able to fully understand the market to contribute to the project, give relevant recommendations, and prevent costly mistakes.
- What do you expect from the application at the end of the development process? — The answer to this question can help us avoid any false expectations. Some clients ask us to build an MVP. We explain to them that this is a comparatively cheap solution to test an idea and it is not a production-ready solution. However, some decide to release the application to the market and consequently experience problems with scalability and support. There is a rather large time and cost gap between an MVP and a production-ready, scalable solution. They can find themselves tangled within the Iron Triangle, since the quality of the software application and its dependency on Cost, Time, and Scope are not evident to non-technical people. That’s why it is better to ask what the client wants to see in the end. I suggest using the SMART methodology to get a precise answer from the client.
- Who is responsible for the approval of the design and tech approaches on the client’s side? — You need to avoid a situation when, at the end of development, you’ll find out that the Architect or Chief Designer disagrees with your solutions or approaches. It seems unbelievable, but we have had such situations. Responsibilities in the client-vendor relationships need to be addressed and defined early on; otherwise, it is a recipe for disaster.
- What are the critical dates for the product? — A company can have some liabilities to investors or plans related to special presentations, conferences, or marketing activities. There are cases when a client can come to the development team a week before the event and say that they need the completed digital product. Nevertheless, it is better to avoid this kind of situation and establish critical dates at the beginning of the development process.
- How are you going to test your business idea (if needed)? — Some ideas need to be tested before the start of the development. It can be done by focus groups, communities, public tests, and limited editions of the application. We often create prototypes in the Marvel App, enabling clients to test their products on focus group and make essential improvements before the major investment.
- Are you planning some marketing activity for promotion? — Some of the marketing campaigns may need additional development, for example, invite code functionality. From the other side, marketers need to know how to measure the effects of the campaign, so we can trace the results of your marketing campaign in the application with various analytics tools. To do that, we implement analytics SDK (software development kit), set up triggers, and release builds to the markets. The marketing team can see the events on the dashboards. One more thing we need to keep in mind is that the app review process by the Apple team can take long and we’ve shared our tips on how to successfully submit mobile solutions to app stores in one of our previous articles. I’ve already mentioned that the development team must know the critical dates. Here is a good example from a real project — on Friday evening, we’ve found out that on the following Monday morning, the client plans to initiate a big marketing campaign. As a result, we needed to deploy all the necessary changes and tests throughout the entire weekend.
- How do you want to receive feedback about the product from your customers? — Some clients ask to embed a contact form directly into the application or use the Zendesk/Intercom SDK to get user feedback and continue enhancing the product.
- What is the core functionality of the product? — I think this question is obvious. Every client’s answer brings up tons of questions from my side because I need to know what the client means from the technical perspective. The software development process is complex. The same business requirements can be achieved with totally different architectural approaches. Gaining a higher level of transparency regarding the digital product’s functional requirements only ensures a more suitable software solution that my product development team can develop.
- Is there some groundbreaking feature you want to implement? — Your application must be different from other solutions on the market. Some clients come with a clear vision of what can make the product different. Nevertheless, some of the clients want to have a clone of Facebook or Uber. In these scenarios, our product development team works with such clients to find key differentiators for their digital products.
- What are the requirements for data storing and data deletion in your sphere? — Every market has its own rules. The General Data Protection Regulation (GDPR), Payment Card Industry Data Security Standard (PCI-DSS), and Health Insurance Portability and Accountability Act (HIPAA) have set the rules that you need to take into account during the software architecture development. Clients always forget that users have a right to ask to delete their personal data (according to GDPR), and to close or restore their accounts. This functionality must be on the IT software architect’s list. Another case is about storing photos, videos, and other documents. Software applications need to control access to users’ personal information.
- Do you have regulatory requirements in your market? — For example, fintech industry has many requirements for reports about money transactions that must be sent daily.
- What is the list of the functionalities you want to implement in the future? — This question is important for architecture solutions. Clients can have a vision for a few years ahead.
- Who will take care of the digital ecosystem after the development is completed from the vendor’s side? — Clients usually forget that they need to support the product, check servers, update versions of the third-party integrations, and so on. DevOps is one of the most important roles for post-release support.
The questions I’ve mentioned above are not the complete set that I usually ask. However, this list can help you understand the digital product better and manage your client’s expectations.
As you may have noticed, there are no questions about the budget for development. Generally speaking, the creation of qualitative software is not a cheap process. The first step for the outsourcing company is to understand the product and goals, and only after that have a more thorough discussion regarding the cost. We can always develop a quick MVP solution; however, a client should understand that development of a production-ready solution requires time.
By the way, don’t shoot yourself in the foot: record your meetings, take meeting notes, and send them to everybody for confirmation.