Designing B2E Software: Discovery Phase

General Considerations

The discovery phase is one of the phases of the software development lifecycle. It begins first and aims to understand project requirements and objectives clearly. Let us start with several important notes:

• As the customers of a B2E product are the employees of one organisation, it is easier to get access to the end users and closely research their working routines, pain points, and desires.
• There is no direct competition between B2E products, as it is in the organisation’s interest to keep a monopoly of products, thus increasing complexity and costs.
• Revenue is not a part of a B2E product, while the organisation plays a significant role as one of the beneficiaries of the well-performing application.

Objectives of the Discovery Phase

Let us start with the straightforward list of objectives product managers should achieve during a Discovery Phase.

1. Identify User Needs: Understanding what employees need from the software, gathering insights into pain points, preferences, and expectations.
2. Define Business Goals: Aligning the software’s functionalities with the organisation’s strategic goals ensures the project delivers tangible business value.
3. Assess Technical Feasibility: Evaluating the technical requirements and constraints helps in planning the project realistically.
4. Estimate Resources and Timeline: Providing a clear picture of the needed resources, including time, budget, and personnel, helps set realistic expectations.

User Research

Conducting user research is essential to gather detailed insights into employee workflows and behaviours. Product teams need to involve multiple stakeholders — internal employees, department leaders, and internal IT teams — in the process of understanding employees’ needs, pain points, and workflows. Legal and compliance requirements should be included as soon as possible, as requirements on data warehousing, information access, and sharing may have a direct impact on the result of a discovery phase.

Workshops are the most efficient way to get a solid understanding of users’ behaviour in this phase. In the B2E context, it makes more sense to involve a significant number of end-users. This shifts the focus from vague business objectives to improving internal employee experience and aligning with organisational goals. An employee-centred approach yields better, long-lasting, tangible results compared to a generic workshop suitable for B2B and B2C segments.

Competitive Analysis

One reason the B2E segment exists and companies decide to design and build their own software applications is that no such product suits existing needs. There are no direct competitors, and there is no easy way to draw inspiration or analyse what others have done. However, the team should focus on other tools and approaches that face the same challenges but in different industries.

For instance, if the team is building an external-caused risk analysis tool in the financial vertical, product managers and designers could draw inspiration from weather forecasting and analysis tools. In most cases, the real competitors of B2E systems are Excel for data-related processes, email for feedback-related activities, and PowerPoint to store organisational knowledge.

Requirements Definition

Based on the insights gathered, a comprehensive list of requirements is drafted, including functional requirements (specific features and functionalities) and non-functional requirements (performance, security, usability). Prioritising these requirements is crucial for effective project planning and scope management.

Teams should be aware that in the process of translating needs into requirements, stakeholders lean towards overcomplication and overestimation of future needs. User experience is paramount in B2E — the software must be engaging, easy to use, and designed to fit seamlessly into employees’ daily routines.

Prototyping and Feedback

Creating low-fidelity prototypes or mockups allows for early visualisation of the software. These prototypes can be shared with stakeholders and end-users to gather feedback. Iterative refinement based on this feedback ensures that the design aligns with user expectations.

The prototyping step is the most valuable, as stakeholders find it easier to react and respond to something visual like a wireframe or a prototype than a written user story or a diagram. Product managers and designers could verify hypotheses on a daily basis and get a solid understanding within two weeks of the discovery phase.

Technical Assessment

In collaboration with the IT team, a technical assessment is conducted to evaluate the feasibility of the proposed solution. This process includes reviewing existing infrastructure, identifying potential integrations, and assessing any technical risks. Unlike in B2B or B2C realms, the team could precisely define the necessary list of integrations and all integration details.

Project Planning

The final step of the discovery phase is detailed project planning. This step includes defining the project scope, creating a timeline, estimating costs, and identifying the team members who will be involved in the development. A clear project plan sets the stage for a smooth transition into the design and development phases.

Summary

The discovery phase is crucial in the successful development of B2E software. It lays the groundwork for a product that truly meets users’ needs and aligns with the organisation’s strategic goals. The main takeaways from the B2E approach of the discovery phase are:

• The discovery process for B2E applications is somewhat similar to B2B and B2C, but several essential nuances exist and should be considered.
• User research should be conducted more precisely, as there is better access to future users.
• User experience plays a significant role in designing B2E systems, while scalability and documentation play secondary roles.
• Standard methods of competitor analysis may not work in B2E, so a different approach should be taken.
• Prototyping and quick turnarounds yield reliable, tangible results compared to other methods of requirements gathering.