As a business team we are part of defining a product goal and help it materialize in time by using different processes, occasionally following our gut and by maintaining the connection between people sharp and alive. 

Business analysis starts at the very beginning with a conceptualization stage where you basically identify the need of a new product, however I would say that it all begins with an idea. 

A concept. That first raw idea that comes in would have to encapsulate the entire future product vision but it needs to be “translated”. It needs breaking down. 

Thus the first questions that arise are: “why do we need this? What benefits will it bring? How are we going to do it? What do we need? Who are we targeting?” 

All these questions are answered by several business processes that should and must start at the very beginning: 

  • Market analysis 
  • Gathering stakeholder input 
  • Analysis of industry trends 
  • User research

One of my favorite psychological ways of understanding and keeping users loyal is the Hook Model. Three primary instincts of a human being based on variable rewards. If we come to think about what we’re searching for in a product, as users, one of the first things we think about is “What do I get by doing this?” What is my reward?”. 

Based on this assumption the following rewarding concepts took birth: rewards of the tribe; of the self and of the hunt. As humans our first instinct is to search for a bargain, hunt for a better way of doing things; improve ourselves. Tribe would help us to share our accomplishments via social media while the rewards for the self will be to scratch something off our to-do list. Thus from my point of view part of first analyzing a product is to understand on a psychological level the target audience. 

Why establishing trust and strong communication is key to success in product management?

To move forward into creating a successful product the business idea is moved onwards to a development team that can follow different ways of working, methodologies or frameworks. 

Following the creation of this team a relationship needs to be established between all the parties involved: stakeholders and product team; product team and the development one; the development one and stakeholders via the product. We fail sometimes at this stage as relationships just like in our day to day life are built on trust. So going back to my first statement to “where the business analysis starts” it starts with an idea and it continues to thrive based on trust. Stakeholders trust their business team with giving them the power to analyze their idea while the product trusts the development team to take that idea further and convert it into something tangible. 

How can we keep this trust between all parties involved in the development process in a few steps:

1. Involve technical people in business discussions after breaking down the requirements

  • Take a leap of faith and try to explain to your people how the business works, how it builds and what it needs to thrive. 
  • Explain to the technical team what involvement we have in fulfilling the desires of end users.
  • Include people in conversations and ask for their opinions.

2. Involve stakeholders in discussions 

  • After implementing a feature ask for the stakeholders opinions and take them into account.
  • Keep them involved in the development process as well, invite them to your meetings, make them feel like they’re part of all the steps you’ve been taking.

3. Maintain a close relationship with people 

And on this topic everything else should follow. We sometimes forget that we work with people and people need to be listened to. They need to be understood regardless of the domain of work. Keeping a close relationship with your team will only bring you benefits in the long run. People become more extroverted if they feel safe so create an environment that is safe for everyone. This doesn’t have to be blocked on a single job title as “Scrum must do this; Product must do this” we all have to do it. In my mind that is the definition of a working thriving team.

4. Don’t rigidise everything. Be agile. 

  • As business people we must try to be agile, not like in the methodology but in the real sense of the word. Try to adapt to people’s needs; both the development team and stakeholders. Use empiricism when something fails. Try new ways. Push people to thrive and keep them in the loop.  

5. Take ideas into consideration regardless of where they come from

  • Listen to your team, they might have more insights on a subject that you are struggling with. Empower them to discuss requirements and tickets and ask for their opinion. Their opinions matter everywhere but mostly in business decisions. 

However besides keeping trust at a peak point and people happy from all sides as part of the business team there are several other processes to take into account like risk management, prioritisation; analysis and planning; design and development; testing and validation and so on and so forth but mainly product teams work for the customer. For the benefit of the customer. In all the rush and entangled ways of working and processes we must keep in mind that what we’re trying to build needs to satisfy the end user first. Like with accessibility. You don’t have to think of it as “more work; more analysis; more stories to write” but to think that if you do it a lot of people would benefit from being included. 

How do we succeed on the business side? 

To be honest, sometimes only based on a gut feeling but that doesn’t always have the best outcome. From my point of view one of the crucial and early steps to follow when wanting to thrive on the business side is to understand the end user and to gather data while user testing and after releasing. For a project to be successful we need to define the success metrics and there are many ways to measure those. One of my favorites is the net promoter score that mainly measures the likelihood of people recommending your product to other people. NPS will measure your customers satisfaction and loyalty and it’s something to take into account if you want your product to triumph. 

Thus after user research that usually comes after understanding the product vision, the analysis of the business requirements begins. In the life of a product person requirements represent the centerpiece of everything. They have to be clearly defined and understood by the business first and then translated into specific user stories that will help the development team to understand them too. But it all starts with a conversation between the stakeholders and the business side followed by the BRD writing; the breaking down of the requirements; the prioritization; the user story writing; the solution design; the discussions with the development teams and so on and so forth.

But our job, as a product/business team is to maintain and refine the requirements as much as possible so the development team can understand what we want. Coming up to my first point of “involving people in business discussions” that will help everyone get an idea of what this product should look like. 

As a last note on business development product do not need to be technical or non-technical, the business team needs to be in the middle. We must understand how we’re building the product and how the vision might change when a technical pair of eyes takes a look at it but at the same time we must understand the business requirements and look at those from a product side of things. 

In the end, one of the most important things in business is to build trust.