Translating Business Needs into Technical Solutions

Sometimes it is challenging to understand what a business truly needs and how to effectively translate those needs into code. Stakeholders often lack technical knowledge and want something on yesterday, while developers strive to adhere to best practices and use the latest frameworks and libraries. Meetings between them can lead to conflicts and, potentially, dissatisfaction with the final product.

Here, I will address the key aspects to consider when dealing with business requirements. We’ll explore what questions to ask and how to find a balance between business and technical needs. This will be particularly useful for Engineering Managers, Architects, Team/Tech Leads, and anyone frequently interacting with business representatives, such as Product Managers, Business Analysts, or other sponsors.

Build communication efficiently

Some may argue that a system design interview helps identify a candidate’s ability to build a complex system, but in reality, it doesn’t work like that. Typically, in an interview, clarifying functional and non-functional requirements is straightforward, with prepared answers from the interviewer. In the real world, however, this process is more complicated. Stakeholders may be uncertain about many aspects or unaware of potential bottlenecks. It is our responsibility to propose the best solution based on the available information. Additionally, understanding business priorities is crucial, as you often have to balance quality, cost, and speed.

Functional requirement

To fully grasp the feature, start with a detailed session with the sponsor to discuss all aspects. The more questions you ask at this stage, the more information you’ll gather. Your goal is to address all potential corner cases, preparing you for “What if?” scenarios. You need to clearly understand what the business wants, why the feature is important, and how it will function. For example, if it involves creating a new screen with updates, consider when it will be created, who the users are, and whether the information needs to be updated in real time or can wait until the screen is opened.

Remember, sponsors are people too, and they might overlook details. Speak in business terms during your conversation. If you can’t explain something simply, it likely means you don’t fully understand it. At the end of the meeting, document the feature description or update any existing documentation. Don’t rely on memory, even for small features.

Nonfunctional requirements

Nonfunctional requirements are crucial, and it’s easy to assume that any system should work without downtime and be able to scale immediately to millions of users. However, this is a common misconception. Typically, the business knows the current number of users and expects growth based on specific marketing campaigns. For instance, if your application currently supports 5,000 users and the system’s limit is 10,000 users, inform the business. This doubling of capacity might be sufficient given the current usage and expected growth.

Consider how critical the feature is to the entire system: Can the application function without it, or is it indispensable? For example, if it’s a suggestions menu, it might be acceptable for the feature to be temporarily unavailable if issues arise. For instance, back-office operations can tolerate slight delays without optimization, real-time user interactions might require immediate accessibility and performance.

Consider price costs

New features can increase costs, such as infrastructure changes or service subscriptions. The cost can vary significantly depending on the solution. If the budget is not aligned, discuss this with the sponsor. Remember, feature implementation involves not only development costs but also ongoing maintenance expenses.

For example, using AWS Aurora can be very expensive for large data storage. Alternatively, configuring your own database on a separate VM may be more cost-effective when dealing with vast amounts of data, though it requires significant development effort. The best choice depends on your qualifications and the specific needs of the service.

You must know your codebase

Once you have handled all functional and non-functional requirements, it’s time to determine how the feature will be implemented and prepare a list of tasks. Consider all aspects of technical implementation carefully. Unlike a system design interview, where you might choose databases based on preference, your company may use specific technologies or have constraints such as databases with read or write issues, requiring scaling and additional costs.

The same applies to caching. You might think it’s easy to cache requests, but consider whether a caching system is already configured, if the requests are suitable for caching, and what TTL (time-to-live) would be appropriate. If you’re unfamiliar with some part of the code, seek assistance. Asking a question will take around 5 minutes but if you make a mistake and not include something it might cost you weeks in the best scenario.

Although, when the business asks only for an approximate estimate, you don’t need to dive deeply into the details or search through the code. Instead, consult with developers or rely on your knowledge of the system to provide a reasonable response.

Find trade-offs between tech and business

When you feel that using the open source library will increase the development and this library is well known, consider integration benefits, instead of writing everything from scratch. If any service can be bought and it would save costs of development please do it. If you feel that this feature may be really hard to implement, it would be better to discuss other options. The best solution is the simplest one. Almost 99.99% of all technical problems you face have already been solved, it is just a matter of finding the right approach.

Sponsors don’t know the complexity of the implementation and sometimes it might be better to sacrifice quality a little bit but release something instead of long-run development with plenty of bugs. It is a very fragile edge between interest to play with new technology or framework and deliver a feature based on known solution. I suggest discussing the opportunities of integrating something new into a project as a separate task. Just describe what you want to achieve with that. Everything can be sold but please don’t try to sell technical improvement for certain feature development if it is not necessary. There will be plenty of unknowns and the result can be unpredictable. If you really want to integrate something new, ask for a spike, prepare benchmarks and try to convince businesses in their language that this would be necessary, e.g. clients will give updates twice faster.

Common mistakes

Never say just “no”. Please elaborate!

As mentioned, the business often doesn’t understand technical details. When you say something is impossible, you need to explain the specifics in simple terms and outline the cost implications. Most features are feasible; it’s usually a matter of time and budget. For instance, you could say: “Our service currently has a bottleneck due to many queries hitting the same database. To implement this feature, we need to add more queries, which could slow the system down by 2 seconds. Alternatively, we could refactor the system to handle the load better, but that would require at least a month of development.” This way, you provide a clear choice: either a 2-second increase in page load time or a month of development work.

Consider your team qualification

If your team lacks expertise in a particular area, inform the stakeholders. This significantly increases development risks. You need to decide between allowing your team to dig into the new technology or outsourcing the work. While outsourcing might take longer, it can bring in a professional with relevant experience who is ready to collaborate.

Assess your resources carefully. For example, if your team specializes in server development using the Flask framework and stakeholders want to integrate and train a specific AI model, it might be best to hire a dedicated expert or team for this task. Explain this to the sponsors, highlighting the benefits of bringing in specialized skills to ensure project success.

Never lie! If you don’t know or are not sure, then say it.

Never say anything to the stakeholder unless you are not sure. Especially never promise any estimation. In this case you will be the person you command and your stakeholder blame and sooner or later it will not end up very well. Even if developers have almost finished the investigation but the results are not accurate, don’t show them to the stakeholders. In best cases, you may be lucky and your estimation will match the reality but on a long distance it will ruin your career. Stakeholders want truth even if it is not very promising.

Your estimation will never be accurate

Almost all estimations fail. It is normal. You cannot consider everything. Your responsibility is to include it in estimation during tasks planning. There are plenty of articles dedicated to estimation techniques and you can get familiar with them. I will just say that always include a percentage of risks to each estimate depending on how confident you are but if the percentage is bigger than 10–20 on the tasks it means you have not investigated the requirement properly or the feature is too big. Of course, for high-level estimation, the value could be bigger but it is a different story.

Conclusion

Nowadays it is very popular to use Scrum and adjust changes according to the sponsor feedback but it does not mean that we must completely ignore business at the beginning and just rely on methodology. Remember, each sprint costs money.

I hope all mentioned here will help to build a clear and professional relationship between business and technology. I believe with the right approach it is possible to cooperate and be able to predict risks and provide more or less accurate estimates. I agreed that sometimes things may go out of control but it is our responsibility as tech guys to be prepared for this and explain it to our stakeholders.