Hey, engineer, do you understand my business?

How to translate business needs into tech language

Subscribe for our newsletter
close
Subscribe for our newsletter

    Over the past few years, startupers have been eager to learn “the Uber Way” – how to exploit proper IT solutions for creating a product that could offer users an intuitive interface and shake up their respective markets. This fascination soon led to the popularization of “uberization” — becoming so sought-after it practically became its own buzzword!

    Ingredients of product success

    But Uber, likewise many other successful products, has something that stands them out from the range of products that failed.  Uber’s success is powered by more than just a great market fit – its engineers have also crafted cutting-edge technology that perfectly reflects the original business plan. Beyond impressive technical savvy, Uber showed an outstanding understanding of what customers really wanted and needed to create a winning product!

    A product journey is a way that consists of different stages and combines a lot of people. The total scope strongly depends on what you plan to develop – the corporate IT solutions require another approach than developing MVP for startups.

    But there always is something at the beginning. Behind all great products lies a dream that turned into an idea.  Understanding it in its original form and turning it into a product is one of the biggest challenges the IT world faces, whether the idea is small or huge. Today we want to discuss what needs to be done for the initial idea to be translated into an appropriate tech solution.

    Why do misunderstandings occur?

    During our work, we faced a lot of different clients that had proficient knowledge of their business; however, when it came to the technical part of the implementation, they needed some guidance (that’s why they hired us). Although IT solutions for business can significantly streamline complex processes and boost revenue, the final success depends on effective collaboration between all stakeholders and eliminating all bottlenecks.

    Someone can say: “Okay, there are people that have an idea on the one side and engineers that can implement the necessary solution on the other side, so what else do you need to make it happen?”

    In the real world, that is more complex. And the most popular reason why the products failed is the discrepancy in translating business needs into a product roadmap understandable to all stakeholders. The gaps can occur at any stage, but in the initial stage, when the product idea has to be decomposed into a software architecture and development plan, the mistakes are very painful. During the work process, a lot of misunderstandings appear, which can be caused by different reasons:

    • The unfamiliarity of the new domain
    • Stakeholders use their internal slang
    • Product Complexity (the high-level vision of the product isn’t decomposed into more simple modules)
    • Stakeholder requirements must be clearer, have ambiguity, edge cases, etc.

     Who is a Business Analyst, and why do we need one?

    To ensure the client’s requirements are captured correctly and then transferred to the tech team, we need someone in the middle who can serve as a bridge that will unite the business shore with the tech one. 

    Of course, we’re talking about the Business Analyst role here. 

    So again, who is a Business Analyst, and why do we need one?

    It is someone with project domain knowledge and can communicate with the client in an understandable language. At the same time, it has appropriate tech skills that allow translating the client’s business needs into technical requirements that are understandable for the development team. Such an approach is highly important in outsourced IT solutions, as the outsourcing engineering team must not only properly catch the idea of the product but be able to select the most appropriate tech stack.

    To ensure that our BA approach is as effective as possible, we created the Expectation Management System (EMS) that allows us to align with the List of Deliverables that will guarantee the successful execution of the project.

    Below are a few things we do to provide high-quality expertise supported by our Expectation Management System.

    Now tell User Story

    Considering there are a lot of different domains, there is no way you can be an expert in each one. That’s why we’ve implemented a proactive approach for our business analysts: we conduct a pre-discovery phase during which our specialists get familiar with the domain of our customers in includes: 

    • Searching & familiarisation with the available content (articles, reports, case studies)
    • Watching the domain-related videos
    • Conducting a Market analysis (qualitative and quantitative)
    • Viewing open jobs and their description

    This is the minimum required from our specialists to understand our clients better. The mentioned phase is crucial for preparing the most relevant questions, which, in turn, allows us to save a lot of time and be on the same page with our clients. We use the individual approach to each case as the pre-discovery phase for developing IT solutions for manufacturing could differ from the software development for e-commerce.

    After the pre-discovery phase is done, we are better prepared for the discovery phase. We can:

    • Ask better questions
    • Set up the correct priorities
    • Avoid assumptions
    • See a strategic goal of the client and align it with the development team.

    All the requirements gathered during the discovery phase are outlined in the form of User Stories that are understandable for both: the client and the development team. Each User Story is followed by a List of Acceptance Criteria that includes specific information on how it should be implemented.

    Example of User Story

    We understand that some of our clients prefer visualization over textual representation. To ensure that we understand them right and not overwhelm them with tons of text, we create business process modes that are represented in the form of a diagram with a list of actions, transitions, and events combined into processes.

    This allows us to:

    1. Demonstrate how the solution (or its separate process) will work
    2. Cover potential edge cases that were not determined during the requirements-gathering sessions
    3. Build a better internal solution structure 
    4. Make sure everyone is aligned on how the solution will work.

    Sometimes, we experience cases where the only way to ensure we understand the client is to demonstrate the solution. But how can we do it when the development phase hasn’t even started yet?

    For cases like these, we create prototypes of the solution. This way, our client will be able to recreate real-life use cases that will take place within the solution that will be implemented.

    To share our experience with the team, we create case studies of the applied approaches, the circumstances where they were applied, and the conclusion of whether they succeeded or not. This allows us to use our experience to build new approaches or utilize ones that work best for our clients and us.

    How to be on the same page? Tips from Business Analyst

    I want to share some tips for the Product Team that could be useful for more effective collaboration with the engineering team:

    1. Think and communicate like your application’s end user. Try not to use complex professional terminology, even if you develop a narrow solution. 
    2. Prioritize the user’s benefits. As it is very hard to satisfy all possible users’ expectations, choose one or a few of the most important, without which your application can’t stand out from the competitors.
    3. Share with Business Analyst and development team the reasons why the existing solutions can’t satisfy the customers. So they can capture the best ideas on how to develop better solutions. 
    4. Be open to new ideas, and evaluate every question, even if it seems very stupid.
    5. Be friendly with numbers and facts. If you request a solution that overcomes the competitors, provide relevant numbers you would like to achieve. For example, if you detected that your competitors failed due to traffic overload, share it with the engineering team. They can develop systems that support the necessary amount of user requests.
    Subscribe for our newsletter

      AI for Businesses: Common Biases and Their Refutations
      AI | BUSINESS | 13 May 2024

      AI for Businesses: Common Biases and Their Refutations

      Contact Person
      Chief Marketing Officer
      Why Transformation Efforts Fail: 11 Reasons and How to Finally Triumph
      BUSINESS | 29 Jan 2024

      Why Transformation Efforts Fail: 11 Reasons and How to Finally Triumph

      Contact Person
      Content writer
      Why Technical Due Diligence is Critical for Startup Exits
      STARTUPS | 10 Jan 2024

      Why Technical Due Diligence is Critical for Startup Exits

      Contact Person
      Chief Technology Officer
      Risk Management in Software Engineering
      LEADERSHIP | 06 Dec 2023

      Risk Management in Software Engineering

      Contact Person
      Chief Marketing Officer
      Top 5 Web3 Applications
      WEB 3.0 | 12 Oct 2023

      Top 5 Web3 Applications

      Contact Person
      Engineering Director
      12 Essential Skills for Developers to Succeed in Web 3.0
      WEB 3.0 | 08 Sep 2023

      12 Essential Skills for Developers to Succeed in Web 3.0

      Contact Person
      Content writer
      Time and Materials vs. Fixed Fee
      BUSINESS | 11 Aug 2023

      Time and Materials vs. Fixed Fee

      Contact Person
      Content writer
      Custom Marketplace Development in 2023
      MARKETPLACE | 21 Jul 2023

      Custom Marketplace Development in 2023

      Contact Person
      Content writer
      The E-Commerce Trends 2023
      E-COMMERCE | 09 Jun 2023

      The E-Commerce Trends 2023

      Contact Person
      Content writer
      IT Support 2023: What to do if a user wants an instant response?
      IT SUPPORT | 01 Jun 2023

      IT Support 2023: What to do if a user wants an instant response?

      Contact Person
      Chief Technology Officer
      Successful UX Audit: Tips and Best Practices
      UX | 19 May 2023

      Successful UX Audit: Tips and Best Practices

      Contact Person
      Content writer
      Modern software development: Coffee, laptop, and AI
      AI | 28 Apr 2023

      Modern software development: Coffee, laptop, and AI

      Contact Person
      Content writer
      What is CTO as a Service?
      BUSINESS | 13 Dec 2022

      What is CTO as a Service?

      Contact Person
      Chief Marketing Officer
      New Trends in Energy Trading and Risk Management Software

      New Trends in Energy Trading and Risk Management Software

      Contact Person
      Chief Technology Officer
      Navigating Software Compliance and Security
      COMPLIANCE | 12 Feb 2025

      Navigating Software Compliance and Security

      Contact Person
      Chief Executive Officer
      7 Common Mistakes in Software Requirements Specification
      REQUIREMENTS | 19 Sep 2024

      7 Common Mistakes in Software Requirements Specification

      Contact Person
      Content writer