Progress Doesn’t Always Look Like a Launch

When a team has invested time in building a tool, people usually want to know whether it’s live and what impact it’s had. The work leading up to that decision can produce valuable results of its own.

A prototype can help you understand what users need, clarify your company’s requirements, and show what your team can build. It can lead you to change the scope or decide an idea isn’t worth pursuing. The skills and relationships developed along the way can also give your team a head start on the next project.

For People and Talent teams using AI to build custom solutions, getting the tool to work is one part of the job. You’re also taking on responsibilities a product team would normally handle, which may be unfamiliar if you’ve mostly bought and configured software. Which data can it use? How will access be controlled? What will Security and IT require before launch? Who keeps it working afterward? Working through these questions gives your team knowledge it can use on future projects, even if the first version never launches.

Give people something to react to.

In a previous role, my team wanted to make our People data more useful by helping leaders find relevant insights and act on them. Building everything we envisioned would take time, so we started with a smaller tool and used AI to help with the build.

The initial tool used a limited set of data and simple thresholds to flag cases for business partners to review. We built a visual interface so they could see where attention might be needed and decide whether to act.

Having a prototype made our conversations with them much more useful. Business partners could point to what helped, what needed work, and what would save them time. Seeing the tool also prompted new questions and ideas for how they could use it.

Our business partners were involved throughout the build and agreed on what we were developing. By the time we were ready to launch, though, they were too busy to start using it. Adoption required capacity as well as agreement. With a broader tool already in development, they chose to hold off on using the first version.

That broader tool brought together additional signals from our People data and incorporated the initial threshold model. Feedback on the first interface helped shape the new one. The first version became a foundation for what we built next.

Each build gives the next one a head start.

Building your first internal tool teaches you a lot about what it takes to run and support it. As you work through security requirements, data access, and support for an actual application, you get a clearer picture of what’s needed and uncover questions to address.

For us, that meant figuring out security and access requirements, data flows, where the tool would be hosted, and which technology to use. We also got a better sense of what we could build and where we needed help.

We already had relationships with Security, IT, and our People and Talent partners. Bringing them into the build gave them something concrete to respond to. They could see what we were trying to accomplish and contribute while there was still room to make changes.

By the next build, we could draw on those conversations and reuse much of the technical work. We had a better sense of what people needed from the interface and how the tool would fit into their day. That understanding helped us build faster and get subsequent tools live sooner. Each project still needed its own review, but our experience helped us make informed choices earlier.

Using AI to build real prototypes taught us what it would take to make them work in our organization. Someone has to respond when the data looks wrong or the tool breaks. Users need a way to give feedback, and someone needs to be responsible for acting on it. All of that needs a plan before the tool goes live.

Be specific about what you learned.

People and Talent teams should be willing to try ambitious work and build toward it in smaller steps. That approach gives us room to test, get feedback, and adjust as we learn. We also need to explain what came out of the effort. If we say we learned a lot, we should be able to point to something we changed, reused, or decided against as a result.

Before starting another project, I recommend working with the team to agree on the question the first version needs to answer and how much time we’re prepared to spend answering it. I’d involve users and internal partners early enough for their feedback to shape the work. Before committing to another phase, I’d assess whether there’s enough value to continue and whether people have the capacity to use and support what’s being built. Sometimes that will mean changing the scope or stopping.

Learning doesn’t automatically make every experiment worthwhile, but when it changes a decision or makes the next build easier, it deserves to factor into how we assess the work.

For us, some of the first prototype’s value showed up in the tools that followed. Looking only at whether that first version launched and what it delivered on its own would have missed that. A launch is one kind of progress, and what we learn and carry forward should be counted, too.

Daniel Morales

Senior Manager, People Solutions & AI, Human-Centric AI Council