Hey, engineer, do you understand my business?

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:

Demonstrate how the solution (or its separate process) will work
Cover potential edge cases that were not determined during the requirements-gathering sessions
Build a better internal solution structure
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:

Think and communicate like your application’s end user. Try not to use complex professional terminology, even if you develop a narrow solution.
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.
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.
Be open to new ideas, and evaluate every question, even if it seems very stupid.
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.