A practical home for people operations

People operations often crosses several teams before a task is complete. A manager needs to prepare for a new colleague, IT needs to arrange access and another person needs to confirm that the practical details have reached the new starter. A founder could build a BVHR product around making one of those handoffs visible. The first version would have a small, concrete job: show who owns the next action and what completion means.

Start with a handoff, not an HR suite

I would resist beginning with an all-in-one platform. Pick one workflow in which an owner is repeatedly unclear. For example, a manager requests the setup for a new starter, but the request does not include a confirmed start date or the systems they need. The product could help the manager supply those details and help the receiving team acknowledge the request before the start date approaches.

Observe the current process with the people doing it. Ask them to walk through a recent example using the actual sequence of events. Where did the request begin? Which details arrived later? Who noticed the missing step? A founder needs that picture before deciding whether the first solution is software, a clearer checklist or a changed team agreement.

Make the work item useful to both sides

A prototype could include the event that starts the work, an owner, required information, a due date and a definition of done. Those fields should answer real questions. If a field does not change what someone does next, leave it out of the first version. A concise request is easier to test than a large form whose purpose is unclear to the person completing it.

The CIPD’s induction guidance frames onboarding around welcoming a starter and providing the information needed to work effectively. That is useful context for the workflow, but it is not a product specification. The founder still needs to identify which part of that experience the proposed tool can actually help a manager complete.

Show state without hiding responsibility

A first interface could show requested, acknowledged, in progress and complete. Each state should correspond to something observable. “Acknowledged” might mean the receiving owner has confirmed that the required information is present. “Complete” might mean the access has been prepared and the manager has received the result. A colored badge alone should not stand in for evidence of completion.

The product should also show exceptions. A changed start date, an unavailable approver or a request sent to the wrong team are ordinary events worth testing. Give users a way to explain the blocker and identify the person who can resolve it. Avoid automatically marking work complete because a deadline has passed or an email has been sent.

Keep the first data model small

A people workflow can easily accumulate sensitive information. Start by deciding what the handoff truly needs and which people should see it. A coordination tool may need a role, team and start date without holding an employee’s wider personnel record. Define permissions before inviting a pilot team, and decide how access changes when someone leaves or changes responsibilities.

For general security design, NIST’s small business cybersecurity resources provide a primary starting point. The founder should translate appropriate guidance into concrete product decisions with qualified support where needed. A pilot is still handling real information if real people and their work are inside it, even when the interface is an early version.

Test the workflow with a small group

A useful pilot could follow one upcoming onboarding journey with a manager, an operations coordinator and an IT owner. Before they use the prototype, write down the decisions you want to observe. Can the requester identify the right owner? Does the receiving team have enough information? Can the manager tell when the task is complete without sending another message?

Review the handoff after it happens. Look at what users did outside the prototype as well as what they clicked inside it. If the important decision happened in a separate conversation, ask whether the product should capture its result or leave that conversation alone. A narrow tool can be valuable without replacing the team’s existing systems or every human exchange.

Decide how the product reaches a buyer

The first buyer might be a people-operations lead or an operations manager with responsibility for coordinating new starters. That person needs to see the workflow in their own context. A short demonstration using a realistic handoff will be more useful than a broad claim about transforming HR. Early distribution could come from direct conversations with similar teams and introductions from advisers who understand the problem.

BVHR could provide one identity across the product, its help pages and the company building it. This is an illustrative direction for a domain buyer, with no software included in the acquisition. The practical next step is a prototype of one onboarding handoff and a pilot plan that names the people, information and decisions involved. Build the smallest useful path, then learn from the work it helps a team complete.