Not every day do you get to say you helped build a product from the ground up.

That’s what the Hyouka team has been doing.

Hyouka is freee’s performance evaluation product, built by Likha and freee engineers & QAs working alongside product managers and designers. It started from a simple gap in freee HR: there was no dedicated product for managing employee evaluations and supporting the processes around them.

Today, Hyouka helps organizations manage evaluations, support employee development, and make better decisions around their people. 

But getting here wasn’t as simple as building one feature after another. It meant three subteams – A, B, and C – figuring out how to build one product together. 

 

Three Teams, One Product

Hyouka has three subteams, each with its own area of responsibility.

At first, it might sound straightforward: each team works on its own part of the product.

In practice, it hasn’t worked that way.

Features built by one team often became the foundation for another. ‘Formula’ became an important part of ‘Sheet Builder’. Supporting features grew into larger areas like ‘Calibration’. And as more of Hyouka came together, the teams naturally found themselves working more closely with each other.

A change in one area could affect another. A problem that started with one team sometimes needed input from the others.

Over time, the teams learned that building Hyouka wasn’t really about three separate areas. It was about making sure all those areas worked well together.

 

Figuring Things Out Together

Building a new product also meant dealing with problems that didn’t always have obvious answers.

Some were technical. Formula, for example, required building complex backend capabilities to support spreadsheet-style calculations inside evaluation sheets.

Others were about the user experience: how administrators could create flexible evaluation forms without making the process unnecessarily complicated.

And as the product evolved, new challenges came with new areas such as Calibration.

There were plenty of discussions along the way.

Engineering decisions had to be considered from a product perspective. QA brought up cases that weren’t always obvious during implementation. Design helped the team think through how features would actually be used.

Instead of each function doing its part and passing things along, the team gradually got used to working through problems together.

That became especially important as the product grew more interconnected.

 

Growing with Hyouka

The team was learning at the same time as the product was taking shape.

New technical problems emerged, architectural decisions had to be made, and plenty of things had to be figured out along the way.

But the bigger change was probably in how the team thought about ownership.

It became less about “this is my team’s feature” and more about “how do we make this work well for Hyouka?”

That meant looking beyond individual areas, asking questions, reviewing each other’s work, and stepping in when something needed more attention—even when it wasn’t strictly part of one team’s responsibility.

It didn’t happen overnight, but that way of working became an important part of the team.

 

More Than a New Product

Hyouka started because freee HR needed an evaluation product.

Building it gave the team a chance to figure out what it takes to create something new from the ground up, and to do it across three subteams and multiple functions.

Different responsibilities, different perspectives, and plenty of problems along the way.

But as Hyouka grew, the teams grew with it.

Hyouka may have started with A, B, and C—but we built it as one product, as one team.