Lets Talk About Business

Table of Contents

Software Business Analysis - This article is part of a series.

Part 1: Presentation of the serie

Part 2: This Article

Part 3: Documenting your business need

Part 4: Technical aspects

Part 5: Make or Buy?

Part 6: Thinking about the future

Part 7: Glossary

Let’s first take a step back and look at the broader development of your application (website, web application, mobile application, etc.):

What’s its market?
What direct or indirect gains do you expect from it?
How important is this application to your business?
Who in your company can be responsible for overseeing this project? Beyond confirming the real business opportunity for your application project, these questions will help you determine a maximum timeline and budget allocation.

Value Proposition
#

The value proposition will be the economic reason for your future application’s existence. It will unambiguously explain what makes your application unique and why it will be a real asset for your customers or for internal use within your company. In other words, it’s about defining the problem(s) your solution will solve. For example: time savings leading to financial gains, reduced operating costs, or a new user experience that brings in additional customers. A strong value proposition drives the decision to start your application project. Conversely, difficulty in finding a good value proposition might signal that you’re heading in the wrong direction, and a new application won’t be a wise investment.

Market research
#

Once the value proposition is defined, a quick market study will help you understand or confirm the environment in which your application will operate. This includes, for example, identifying a target audience with unmet needs and assessing the potential size of that market. Also, analyze your competitors: If all your competitors are using the same application, you should dig deep to understand why. It might not be a coincidence, but rather a sign that it’s the most rational choice for you.

Persona
#

Personas are concise, fictional representations of your key users, based on real data and assumptions about their behaviours, needs, and motivations. It’s more of an intellectual exercise than a science, but it extends previous business analyses. Don’t confuse the number of people with their importance: Even a small group of strategic users can justify creating a detailed persona. A persona helps you design an application that precisely meets the expectations of its future users. It will help you better address their real needs.

SWOT analysis
#

This strategic methodology will help you identify your project’s internal strengths (e.g., strong domain expertise among your employees) and weaknesses (like a lack of budget compared to too broad a scope for the application). Also, list external opportunities (perhaps a new market your application will give you access to) and threats (typically an already well-established competitor)

Internal accountable person
#

Appointing an internal project lead is essential for successful execution. This person will be the central point, responsible for coordinating internal and/or external teams, tracking progress, and making key decisions. Depending on the application’s scope and urgency, this person’s workload could range from a few hours per week to a full-time commitment over several months.

Short- and long-term vision
#

Beyond the first version, have a future “vision” for your application, both short-term and long-term:

Short-term: What are the immediate objectives and minimum viable functionalities to make your application viable?
Long-term: How will your application evolve to adapt to market changes and user needs? You can refer to the article “Thinking About the Future” for more details on this point.

My experience
#

In my opinion, whether your application is for internal company use or intended for your customers, the process of verifying the real need should remain the same. Software development has this “magic” about it: anything you could ever need is achievable; it’s all a matter of budget. It’s up to you to ensure that the requested price will be recouped by your company. This implies staying “reasonable” about the project’s scope and complexity, and, upstream, having clearly defined your needs to get realistic quotes from service providers or vendors. I’ll elaborate on this point in the next article, “Documenting Your Needs Effectively”.